-
Notifications
You must be signed in to change notification settings - Fork 14.1k
alloc: specialize String::extend for slices of str #149694
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
base: main
Are you sure you want to change the base?
alloc: specialize String::extend for slices of str #149694
Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…r=<try> alloc: specialize String::extend for slices of str
library/alloc/src/string.rs
Outdated
|
|
||
| #[inline] | ||
| fn push_str_slice(&mut self, slice: &[&str]) { | ||
| let additional = slice.iter().map(|x| x.len()).sum(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to check for overflow, otherwise it's unsound to do unchecked ptr.adds and copy_nonoverlappings below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, I forgot about the case where multiple strs reuse the same memory by having their addresses overlap, and was operating under the assumption all arguments were disjoint, in which case overflow would be impossible.
What do you recommend doing in the overflow case? just panicing with a generic message? triggering the oom handler to preserve behavior (as that's what the generic implementation would do in the overflow case)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just saturate and let reserve panic from capacity overflow, just like the previous push_str calls would have? I don't know off-hand if there's any significant benefit to actual overflow check vs. saturation in this context.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
d2b3962 to
38ab135
Compare
|
Fixed CI failure and used saturating arithmetic |
|
Finished benchmarking commit (281de2c): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -6.4%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 470.249s -> 470.338s (0.02%) |
Here's a small optimization via specialization that can potentially eliminate a fair few reallocations when building strings using specific patterns, unsure if this justifies the use of unsafe, but I had the code implemented from #148604, so I thought it was worth submitting to see.