-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Expand FlattenCompat folds #82162
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
Expand FlattenCompat folds #82162
Conversation
The former `chain`+`chain`+`fold` implementation looked nice from a functional-programming perspective, but it introduced unnecessary layers of abstraction on every `flat_map`/`flatten` fold. It's straightforward to just fold each part in turn, and this makes it look like a simplified version of the existing `try_fold` implementation. For the `iter::bench_flat_map*` benchmarks, I get a large improvement in `bench_flat_map_chain_sum`, from 1,598,473 ns/iter to 499,889 ns/iter, and the rest are unchanged.
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue r=me if perf looks reasonable (improved or unchanged) |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit fc150d1 with merge 031d8ee87cc71178b63641c7fce0155a5da0aacb... |
☀️ Try build successful - checks-actions |
Queued 031d8ee87cc71178b63641c7fce0155a5da0aacb with parent 83b30a6, future comparison URL. |
Finished benchmarking try commit (031d8ee87cc71178b63641c7fce0155a5da0aacb): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
I think it does look like this went in the right direction, so... @bors r=Mark-Simulacrum |
📌 Commit fc150d1 has been approved by |
☀️ Test successful - checks-actions |
The former
chain
+chain
+fold
implementation looked nice from afunctional-programming perspective, but it introduced unnecessary layers
of abstraction on every
flat_map
/flatten
fold. It's straightforwardto just fold each part in turn, and this makes it look like a simplified
version of the existing
try_fold
implementation.For the
iter::bench_flat_map*
benchmarks, I get a large improvement inbench_flat_map_chain_sum
, from 1,598,473 ns/iter to 499,889 ns/iter,and the rest are unchanged.