Skip to content

&str slicing using SliceIndex is slow #68874

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

Closed
Riey opened this issue Feb 6, 2020 · 2 comments · Fixed by #75121
Closed

&str slicing using SliceIndex is slow #68874

Riey opened this issue Feb 6, 2020 · 2 comments · Fixed by #75121
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Riey
Copy link

Riey commented Feb 6, 2020

Summary

It seems closure in unwrap_or_else doesn't inlined

self.get(slice).unwrap_or_else(|| super::slice_error_fail(slice, start, end))

self.get(slice).unwrap_or_else(|| super::slice_error_fail(slice, 0, end))

self.get(slice).unwrap_or_else(|| super::slice_error_fail(slice, start, end))

I can't make PR because I don't know how can I fix should this code don't use unwrap_or_else? or need some patch for optimizer or LLVM?

Godbolt

https://godbolt.org/z/TBhkjy

Benchmark

Code

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=765da897030741f77b13ce397dc7f882

Result

running 4 tests
test benches::bar_itself ... bench:         195 ns/iter (+/- 0) = 5261 MB/s
test benches::bar_long   ... bench:       2,311 ns/iter (+/- 14) = 5374 MB/s
test benches::foo_itself ... bench:         383 ns/iter (+/- 2) = 2678 MB/s
test benches::foo_long   ... bench:       4,606 ns/iter (+/- 7) = 2696 MB/s

test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured; 0 filtered out
@kevinastone
Copy link

@phjeltman
Copy link

I can't make PR because I don't know how can I fix should this code don't use unwrap_or_else? or need some patch for optimizer or LLVM?

How about adding a #[inline(always)] annotation to the closure, would that work?

@jonas-schievink jonas-schievink added C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Feb 6, 2020
@bors bors closed this as completed in 9892279 Aug 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants