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

itertools::Join is 2X slower than alternative. #577

Open
SteveBattista opened this issue Sep 14, 2021 · 3 comments
Open

itertools::Join is 2X slower than alternative. #577

SteveBattista opened this issue Sep 14, 2021 · 3 comments

Comments

@SteveBattista
Copy link

If you replace:
iterable.into_iter().join(sep)

With

iterable.map(AsRef::as_ref)
        .collect::<Vec<_>>()
        .join(sep)

in Itertools::join the performance is 2X faster.

@SteveBattista
Copy link
Author

Looking at the nightly build, this code is even faster

https://doc.rust-lang.org/std/slice/trait.Join.html

@KamilaBorowska
Copy link

KamilaBorowska commented Sep 16, 2021

i think this may be impossible to fix without changing Self::Item: Display bound into something else or waiting for specialization. Current implementation has no choice but to either use .to_string() (which has some specializations, but at the same will pretty much always box the values unless they are already a String) or write! (which involves dynamic dispatch and going through a lot of fmt internals) - neither of those is a particularly great choice.

I don't have benchmarks to test it, but I'm somewhat curious how .intersperse(sep).collect::<String>() compares in terms of performance.

@SteveBattista
Copy link
Author

Looking at the code for .intersperse it is much more complicated with two if statements. This is much more complicated than the other code. The other one pulls the if statement out of the loop and then goes though the rest. This would allow for loop optimization and really good pipe-lining in a processor. Looking forward to the test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants