Skip to content

Conversation

@etki
Copy link
Contributor

@etki etki commented Apr 27, 2025

Yet another performance PR, this is probably the most beneficial one among all, avoiding extra stream overhead, zero-sized list, O(n²). It could probably get a whole order of a magnitude speed up if #6113 would be implemented (we can then create a same-sized array and fill it in a single iteration, then create tags without any unnecessary re-sorting).

I'm having too many benchmark reports in my files to be sure i'm picking the right one, so i'll rerun them soon. Just to get a glimpse, this is what i'm looking at and what could be not the latest version (the last ones would be pretty rare in real applications; they would also usually filter around 62 tags out of 64, thus the drop compared to 8/32 combination). Set.of(), available only for java 9+, would be even more performant if supplied by end users.

ignored tags meter tags version ns/op instructions
8 32 main 2793.114 ± 2.144 12508.501
8 32 PR 1595.240 ± 1.976 5541.988
64 64 main 8439.085 ± 7.119 38896.080
64 64 PR 1161.565 ± 1.578 4052.474

@jonatan-ivanov jonatan-ivanov added the performance Issues related to general performance label Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance Issues related to general performance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants