Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

sqrt algo probably doesn't need native optimization

But I assume it would note if that was the case

well, that's the largest thing on the profile, but there is plenty of other small stuff on the profile.

<@U06A03HV1>: Skimming this paper, it doesn't seem this algorithm is meant for cycle detection when the node set is growing too?

Though hm, I guess a new node is trivially disconnected

This is one of those things I would have expected to be figured out in like, the 70s

```Topological Order. It is straightforward to apply the ideas from Sections 2 and 4 to extend the spare and dense strong-components algorithms to maintain a weak topological numbering of the components and/or a list of the components in a topological order. We leave this extension as an exercise.```

Things I miss now that I work in the real world ^^

Punting "obvious enough" problems to the next person down the line

hm... more intuitional fidgety bits. the HKMST paper they refer to has runtime `O(m^(3/2))`... which is _equal_ to the first component of their `O(min(m^(1/2), ??)*m)`

...so let's see which of these is better explained

<http://www.cs.princeton.edu/~sssix/papers/dto-journal.pdf>

thinking about a wholesale move from `pants.engine.exp` -&gt; `pants.engine.v2` (and `pants.engine.v2.legacy` etc - sans the examples and such) - thoughts?

to keep things at least compartmentalized by generation

or do we want to fully sink that into `pants.engine`

i'd be fine with fully sinking if they were in appropriate targets

<https://rbcommons.com/s/twitter/r/3803/>