Use slice parts in PartialEq for VecDeque #31420
Conversation
This improves == for VecDeque by using the slice representation. This will also improve further if codegen for slice comparison improves. Benchmark run of 1000 u64 elements, comparing for equality (all equal). Cpu time to compare the vecdeques is reduced to less than 50% of what it was before. ``` test test_eq_u64 ... bench: 1,885 ns/iter (+/- 163) = 4244 MB/s test test_eq_new_u64 ... bench: 802 ns/iter (+/- 100) = 9975 MB/s ```
|
This is for consideration. Not sure here, it feels like bloat. Ideally we'd trust the compiler with the inlining decisions here but, I'm not sure. It wins microbenchmarks for comparing equal vecdeques for sure. |
bluss
changed the title
|
r? @gankro |
|
@bors r+ The win is clear, the bloat is unlikely to be a problem. |
|
📌 Commit aeb3aba has been approved by |
|
⌛ Testing commit aeb3aba with merge 0efe43d... |
|
💔 Test failed - auto-linux-32-opt |
|
@bors: retry On Wed, Feb 10, 2016 at 12:03 AM, bors [email protected] wrote:
|
collections: Use slice parts in PartialEq for VecDeque This improves == for VecDeque by using the slice representation. This will also improve further if codegen for slice comparison improves. Benchmark run of 1000 u64 elements, comparing for equality (all equal). Cpu time to compare the vecdeques is reduced to less than 50% of what it was before. ``` test test_eq_u64 ... bench: 1,885 ns/iter (+/- 163) = 4244 MB/s test test_eq_new_u64 ... bench: 802 ns/iter (+/- 100) = 9975 MB/s ```
|
@gankro We can always revisit later! llvm will use its judgement for inlining and so on. A target for the future is to improve the slice's own equality comparison. |
collections: Use slice parts in PartialEq for VecDeque
This improves == for VecDeque by using the slice representation.
This will also improve further if codegen for slice comparison improves.
Benchmark run of 1000 u64 elements, comparing for equality (all equal).
Cpu time to compare the vecdeques is reduced to less than 50% of what it
was before.