Optimize Iterator
for IIterator<T>
#3476
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
C++/WinRT uses exceptions for error propagation and unfortunately exceptions continue to be very slow. I hadn't realized how much slower until a customer shared some logs. I decided to take a fresh look and compare the Rust implementation of
IIterator<T>::Current
returningE_BOUNDS
to C++/WinRT's implementation that throws before returningE_BOUNDS
. For a million calls:RoOriginate
): 3.95sSo that's quite a difference. Ideally we can get C++/WinRT to avoid exceptions but this probably merits a tweak in Rust to avoid this pathological case as changing C++ is hard.
This change tweaks the
Iterator
trait implementation on the Rust side to useHasCurrent
to avoid calls toCurrent
and thus avoid those exceptions. With this change, the cost of iteration for C++ implementations approaches that of Rust.Thanks to @JamesMcNellis for prodding me to look into this a bit more closely. He also gave a great talk on how exceptions work that you should definitely check out.