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

Solve performance of values iterators #23

Merged
merged 1 commit into from
Oct 13, 2022
Merged

Conversation

udoprog
Copy link
Owner

@udoprog udoprog commented Oct 13, 2022

This PR solves all iterator performance issues by ensuring that the used iterator implementation that is produced by types such as Set and Map all directly relate to an iterator adapter provided by core::iter (i.e. std::iter).

After some investigation it was discovered that the difference in performance was due to different code generation, in particular when using an appropriately sized array directly it will be unrolled by rustc and LLVM https://godbolt.org/z/aW1fqa4xM.

This is very likely due to the internal use of TrustedLen, which is an unsafe trait the the compiler can use to determine the exact length of an iterator https://doc.rust-lang.org/src/core/iter/adapters/flatten.rs.html#118.

So by using internal iterators even though it leads to more complex typing (somewhat mitigated through aliases) we're able to convince rustc to peel of all abstractions and as appropriate make use of loop unrolling. This means that for example the Map::values iterator should behave exactly like an [Option<T>; SIZE] iterator for non-composite keys.

@udoprog udoprog added the enhancement New feature or request label Oct 13, 2022
@udoprog udoprog force-pushed the solve-iterator-performance branch 2 times, most recently from d6e8257 to 5790995 Compare October 13, 2022 08:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant