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

Efficient flattening of Vec<Result<Vec<T>, E>> into Result<Vec<T>, E> #817

Closed
mo8it opened this issue Dec 12, 2023 · 2 comments
Closed

Efficient flattening of Vec<Result<Vec<T>, E>> into Result<Vec<T>, E> #817

mo8it opened this issue Dec 12, 2023 · 2 comments

Comments

@mo8it
Copy link

mo8it commented Dec 12, 2023

See my post on the Rust forum with benchmarks of process_results in itertools:
https://users.rust-lang.org/t/300x-more-efficient-flattening-of-vec-result-vec-t-e-in-the-worst-case/103841

@Philippe-Cholet
Copy link
Member

Philippe-Cholet commented Dec 13, 2023

Well, I think itertools adaptors are convenient first, not necessarily the fastest in every situation. We are working on specializing fold methods (see #755 and related PRs) to improve on that front, and we would specialize try_fold if we could do it on stable Rust.

If you think that specialize a method of our ProcessResults is worthwhile, then it would surely be a nice addition. Or maybe another method/adaptor?

@Philippe-Cholet
Copy link
Member

A function taking a vector can leverage all its information which process_results simply can't do as it handles an iterator of results, but it's not supposed to do it as it would stop at the first error, which a vector would not do.

Those are two solutions for a similar problem but with different trade-offs.
It's worth knowing but here is more about iterators than vectors, results or flattening so I close this.

@Philippe-Cholet Philippe-Cholet closed this as not planned Won't fix, can't repro, duplicate, stale Dec 26, 2023
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