Skip to content

Avoid overhead of Stream / Iterator in RulesVisitor #3804

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

Merged
merged 1 commit into from
Jan 28, 2025

Conversation

kilink
Copy link
Contributor

@kilink kilink commented Jan 28, 2025

Avoid overhead of creating a Stream in filterRulesVisitingFragmentSpreads, and instead just do the filtering inline in a for loop.

Avoid overhead of creating a Stream in filterRulesVisitingFragmentSpreads, and instead
just do the filtering inline in a for loop.
@dondonz dondonz added this to the 23.x breaking changes milestone Jan 28, 2025
@dondonz dondonz added the performance work that is primarily targeted as performance improvements label Jan 28, 2025
Copy link
Member

@dondonz dondonz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all these performance improvements!

Copy link
Member

@bbakerman bbakerman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did this turn up in a profiler or just getting rid of .stream()s

@bbakerman bbakerman merged commit ece8f57 into graphql-java:master Jan 28, 2025
1 check passed
@kilink
Copy link
Contributor Author

kilink commented Jan 30, 2025

Did this turn up in a profiler or just getting rid of .stream()s

Hey @bbakerman . I am not trying to get rid of all stream calls, this came up when I was profiling an instrumentation implementation. It is true though that in hot code, stream can add quite a bit of overhead. For trivial scenarios like the filtering done in this method it seems straightforward to just unroll it into a loop and avoid the cost.

@kilink kilink deleted the rules-visitor-optimization branch January 30, 2025 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance work that is primarily targeted as performance improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants