-
Notifications
You must be signed in to change notification settings - Fork 310
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
step() slowness #133
Comments
It's not really surprising, .step() is written for general iterators and uses .fuse() among other things (whose performance impediment is well known). |
Thanks for the explanation. I see now that step_by() is only implemented for ranges. |
It's not just fuse, it's a lot of stuff that needs to be covered. Every adaptor could have its own performance story explained. Step could possibly be improved with specialization (also fuse-related specialization). |
One prerequisite for making the best step iterator for slices (like Stride/StrideMut) is to have arith_offset as a stable function. Then specialization to let us do interesting specializations in itertools itself. |
std has Iterator::step_by now. We can deprecate step() when it's stable. |
Step has been deprecated in itertools 0.8 |
I encountered a case where the step() method leads to incredibly slow code:
Replacing step() with the unstable step_by() gives a 100 fold improvement in execution time, as can be observed on the playground here.
The text was updated successfully, but these errors were encountered: