Improved Meter.Id#getTags() performance #6182
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
etki
commented
Apr 26, 2025
| @@ -282,8 +282,14 @@ public String getName() { | |||
| * @return A set of dimensions that allows you to break down the name. | |||
| */ | |||
| public List<Tag> getTags() { | |||
| List<Tag> tags = new ArrayList<>(); | |||
| this.tags.forEach(tags::add); | |||
| if (this.tags == Tags.empty()) { | |||
There was a problem hiding this comment.
It would be better to explicitly check for zero length, as it's possible to construct another instance with zero tags, but we don't have that API.
etki
commented
Apr 26, 2025
| return Collections.emptyList(); | ||
| } | ||
|
|
||
| List<Tag> tags = new ArrayList<>(32); |
There was a problem hiding this comment.
As stated above, 32 is purely a guess and is a subject for discussion
Signed-off-by: etki <[email protected]>
etki
force-pushed
the
meter-get-tags-performance-improvement
branch
from
674a6e4 to
b3fa190
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey. This is a very small and simple PR aimed at a tiny performance improvement: currently, the .getTags() call always allocates a zero-sized array list and then uses a .forEach call (which results in allocating another object for lambda, and, in the worst case, non-inlined call) to populate it. PR checks if list is needed at all, and if so, asks for a list with a space for 32 elements, populating it in a classic loop. The number of 32 is only a guess with no real grounds.
This is definitely not the biggest problem around, so the change is perceptible, yet not a game changer.
Benchmarks from #6174 and Intel N100 fixed at 2GHz were used to estimate the impact. The benchmark uses identifiers with 0-64 tags, where the number of tags in the
modecolumn occurs 90% of time, and other values are distributed evenly in the remaining space.43.379 ± 0.05644.352 ± 0.78271.544 ± 0.18865.575 ± 0.48081.493 ± 0.70472.908 ± 1.04892.932 ± 0.45182.054 ± 1.028120.026 ± 1.511104.113 ± 1.794209.666 ± 2.159143.756 ± 3.422345.139 ± 3.130244.574 ± 7.125618.301 ± 6.336496.224 ± 14.074Please note that some improvements suggested in #6113 (using
Collections.unmodifiableList(Arrays.asList(...).subList(...)or even creating a custom List implementation that would combine all the three) will likely bring these numbers down to tens of ns per call on arrays of any length and make this PR completely redundant.