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

Stream optimization checks #2955

Open
schlosna opened this issue Nov 15, 2024 · 2 comments
Open

Stream optimization checks #2955

schlosna opened this issue Nov 15, 2024 · 2 comments

Comments

@schlosna
Copy link
Contributor

What happened?

Code like stream.map(foo::expensiveConversion).limit(N), stream.sorted().limit(N), or stream.filter(this::someFilter).sorted() does not trigger any warnings for inefficiency.

What did you want to happen?

If one writes code that limits or filters a Stream we should push those predicates earlier in the pipeline where possible to limit the amount of downstream computation and allocations are performed.

@jdm2212
Copy link
Contributor

jdm2212 commented Nov 15, 2024

this is fine:

stream.map(foo::expensiveConversion).limit(N)

this is not fine:

stream.sorted().limit(N)

the latter has a step that needs to touch all elements in the stream (sorted()) whereas the former does not

@jdm2212
Copy link
Contributor

jdm2212 commented Nov 15, 2024

it is also entirely correct in many cases to do stream.sorted().limit(N) if you just want the top N elements of the stream, sorted by some property

it's only dangerous if you erroneously believe that the limit will be applied to the unsorted stream and bound the number of items being sorted

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