Early-building some parts of graph about buck2

[JakobDegen]

Does buck2 know how to execute the graph in this kind of order where we prioritize steps that block larger numbers of other steps?

No, it does not. If I remember correctly, local action execution ordering is currently just a super naive FIFO queue.

For a long time, this wasn't a problem that we cared about for Meta-internal use cases because RE gives you unbounded parallelism. However, we have recently run into cases where we know this causes a slowdown for us too, and so there's definite interest in being smarter.

It's not something that'd really be hard to change implementation wise, the difficult part is just figuring out what a better alternative actually would be. I think the currently favored suggestion was to try round-robin by action category

[zjturner]

Why not a priority queue by number of nodes waiting (directly or indirectly) on the node?

[JakobDegen]

There's a couple problems with implementing that:

1. Dynamic outputs means you can't even know that number. You could assume that each dynamic output is just one action, but that's really really wrong in some cases.
2. Dataflow doesn't really work that way in buck, action execution (and other dice nodes) can't do arbitrary inspection of their rdeps.
3. It's not obvious how you can implement such a thing in a non-quadratic way, keeping in mind that because of concurrent commands new rdeps can appear or existing ones can disappear at any time

Even if you ignore that though, it's not clear to me that it'd be better. If you have one part of the graph which is basically just a path, and another part which is fairly flat but has a large total number of actions, it's pretty easy to continue making the same mistake

[dmezh]

@JakobDegen yeah I figured there could be a complexity constraint on doing this. Could there be a parameter on a rule definition or invocation that just compels buck2 to prioritize building it?

Wrt a priority queue - is it maybe possible to do this on a best-effort basis? Sorry, I'm not very familiar with buck2 internals. Is there some kind of limited window of context we can use to inform ordering of action execution without necessarily doing really deep inspection?

For some context, we are currently using local execution but are planning on using RE. We are going to do a kind of "tiered RE" where individual devs will run a RE server on their local machines that can then delegate to a much larger remote one when it is available. We need to be able to build with no network connection regularly. So we're sometimes running with, sometimes without ~unbounded parallelism available.