perf: avoid retrieving possible_values unless they're used #5267
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vermiculus
force-pushed
the
sa/avoid-pv-expansion-in-help
branch
from
402fa91
to
d281a72
Compare
vermiculus
force-pushed
the
sa/avoid-pv-expansion-in-help
branch
4 times, most recently
from
a819532
to
eae1ee2
Compare
epage
reviewed
Dec 27, 2023
I will say that the general assumption is Possible Values are fast to look up. I'm ok with this optimization being "best effort" but not willing to guarantee we won't look up possible values if they are hidden. So long as you understand that you'll be playing wack-a-mole with this as new problems crop up, I'm fine moving forward with it. |
|
Whack-a-mole seems fine; I can certainly own the fixes to any problems in this space (at least by default). As long as the unit test remains in place :-) |
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_
vermiculus
force-pushed
the
sa/avoid-pv-expansion-in-help
branch
from
84e2015
to
05cd057
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_valuesduring '-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
clap_builder/src/builder/command.rs:long_help_exists_, which at least supports the idea that actually consuming the iterator is not generally-guaranteed behavior whenhide_possible_valuesis set.This seems like an obvious bug 'to me', but I recognize that there might be some angle to this that warrants discussion. If so, let me know and we can put this PR on ice while discussion happens in a tracking issue.