Silly loaded question here. The bash completions h...
# development
w
Silly loaded question here. The bash completions have been sitting on my "need to release" pile for a while now, because there are a bunch of discussions around how/whether to export, how to handle each repo separately, etc etc. I think there is an adequate use case to experiment with dynamically creating completions on tab (which I think Jacob suggested months ago). Solves all kinds of problems with per-repo differences, detecting updates as they're made, etc. However, on my machine that might mean 1-2 seconds lag after tab. Maybe less on M1s (and my soon-to-be, M2).
Will
scie-pants
give us a foothold into lowering the time it takes to run
help-all
? Dropping the need to discover python's should already make a difference, but are there wins that can be taken from there (e.g. updating to Python 3.11 and trying to score a fraction of that sweet, sweet new performance?) Or maybe there is an angle to cache help, and try to bypass some of the startup costs? Just throwing out ideas here, I don't know enough about the startup costs for Pants to offer anything much better than that.
As an example, this is probably a lower-bound for me:
pants help-all 0.47s user 0.06s system 67% cpu 0.777 total
e
The scie-pants binary saves you ~33% startup overhead - ~200ms for me. You still have ~500ms overhead in Pants just to noop.
Yeah, so scie-pants doesn't help much there. Pants itself is still fundamentally slow.
You'd want to generate a cache for help-all that only gets re-genned if plugins added, etc.
w
You'd want to generate a cache for help-all that only gets re-genned if plugins added, etc.
Yeah, essentially - basically changes on
pants.toml
touch
e
Yeah.
w
I just checked, approx 250ms for ./pants to pants for me - lines up with my tests from the past
e
The big problem is that gathering options has to import the world and importing is slow.
w
Ah, okay - that's good to know, also makes more sense