Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perf: Switch to &'static str by default #4223

Merged
merged 6 commits into from Sep 16, 2022
Merged

perf: Switch to &'static str by default #4223

merged 6 commits into from Sep 16, 2022

Conversation

epage
Copy link
Member

@epage epage commented Sep 16, 2022

Originally, clap carried a lifetime parameter. When moving away from
that, we took the approach that dynamically generated strings are always
supported and &'static str was just an optimization.

The problem is the code size increase from this is dramatic. So we're
taking the opposite approach and making dynamic formatting opt-in under
the string feature flag. When deciding on an implementation, I
favored the faster one rather than the one with smaller code size since
small code size can be gotten through other means.

Before: 567.2 KiB, 15.975 µs
After: 541.1 KiB, 9.7855 µs
With string: 576.6 KiB, 13.016 µs

The overall hope is to allow a `&'static str`-only version of clap, so
we need to move off of `Str` where dynamic strings are required.  We
need it here for subcommands due to external subcommands.

This had minimal impact on code size (567.2 to 567.5 KiB)
This is a more familiar type for people and it didn't cost us anything
(in fact it undid the code size change in the last commit).
Originally, clap carried a lifetime parameter.  When moving away from
that, we took the approach that dynamically generated strings are always
supported and `&'static str` was just an optimization.

The problem is the code size increase from this is dramatic.  So we're
taking the opposite approach and making dynamic formatting opt-in under
the `string` feature flag.  When deciding on an implementation, I
favored the faster one rather than the one with smaller code size since
small code size can be gotten through other means.

Before: 567.2 KiB, 15.975 µs
After: 541.1 KiB, 9.7855 µs
With `string`: 576.6 KiB, 13.016 µs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant