We've decided to try using some of our funding to speed up CI.
kbknapp has experience with buildjet in the past which allows us to keep
our Actions and switch out our runners.
As we are charged for `num_cores * time`, increasing core counts could
decrease time, both helping us and keeping costs down.
I chose 8 cores (an upgrade over `ubuntu-latest`s 2 cores) as kbknapp
knew someone who benchmarked things for Rust/Python and found that a
good fit.
I only switched a subset of jobs over to buildjet to focus on jobs where
most of the time is spent on highly parallelizable operations.
Buildjet dropped our Linux test jobs from 8-9min to 2-3min.
The checks and UI-test jobs only improved by 30s-1min each, so I left
them out.
We can iterate as we go.
In some sophisticated situations, these may be expensive to calculate.
One example might be a '--branch' option accepting any single Git
branch that exists on the remote -- in such a case, the remote would
need to be queried for all possible_values. The cost is ultimately
unavoidable at runtime since this validation has to happen eventually,
but there's no need to pay it when generating help text if
`is_hide_possible_values_set`.
To keep '-h' fast, avoid collecting `possible_values` during '-h'
unless we're actually going to use the values in display.
This optimization is repeated for the manpage renderer.
This is trivially based on the short-circuiting logic at [1], which at
least supports the idea that actually consuming the iterator is not
generally-guaranteed behavior when `hide_possible_values` is set.
Note on the 'expensive' mod: This keeps all the possible_values tests
in one file but allows the entire set of tests to be controlled by the
'strings' feature (which is required to be able to use String rather
than str for each possible value).
[1]: clap_builder/src/builder/command.rs:long_help_exists_
