Add MultiTagInsertionFilter #6184
Conversation
Signed-off-by: etki <[email protected]>
Signed-off-by: etki <[email protected]>
| return NoOpFilter.create(); | ||
| } | ||
|
|
||
| return MultiTagInsertionFilter.of(collected); |
There was a problem hiding this comment.
There would be some sense in creating a OneTwoInsertionFilter IF we'd have the API from #6113. This is the case in my company, we insert only a single tag, and getting rid of collection abstractions could have provided extra boost. However, since any addition here triggers the sorting process, there's no sense in creating a special implementation for the most frequent case.
| public Meter.Id map(Meter.Id id) { | ||
| Iterable<Tag> original = id.getTagsAsIterable(); | ||
| Tags replacement = original == Tags.empty() ? injection : Tags.concat(injection, original); | ||
| return id.replaceTags(replacement); |
There was a problem hiding this comment.
Not doing replacement == original check as it's impossible - even if all the injected tags would get overridden, this would not result in the same instance being returned. Calling .equals() is redundant because it involves iterative string comparison, it will outweigh any potential savings on that single allocation.
2 participants
A tiny performance / clarity improvement. There's just one major potential issue with the MeterFilter.commonTags(): as it accepts Iterable, there's no guarantee that end user won't provide List, Set or another implementation that is not Tags, and the downstream code would then create a new Tags instance on every call, resulting in the heavyweight sorting. This PR makes sure that the concatenated instance is always Tags, plus carries some negligible good manners, not recreating an object if nothing has changed and providing a meaningful class name in the stack traces. As with other PRs, we can get a much more significant speedup if we provide an interface to create Tags from already sorted collections (see #6113), as here we can do the same process as in Tags.merge(), preallocating array of a necessary size and doing O(n) iterative merge.
The benchmarks used were the ones in #6174, OpenJDK 21.0.2, Intel N100 at fixed 2GHz. They simulate the worst case, when user provides a list and not a Tags instance. How to read the table: injected = number of tags to be inserted by the filter, supplied = mode of the number of tags in incoming Meter.Id. Incoming Meter.Id may have 0-64 tags, with 90% probability this number equals exactly mode, in other 10% cases it is evenly distributed across other values in 0-64 range. It included some manual editing, so there might be (hopefully not) editing mistakes.
33.160 ± 0.2293.049 ± 0.00130.885 ± 0.0663.065 ± 0.09253.590 ± 0.0693.067 ± 0.11250.770 ± 0.0853.044 ± 0.00151.077 ± 0.0893.041 ± 0.00151.161 ± 0.0923.085 ± 0.17926.964 ± 0.0873.042 ± 0.00152.232 ± 0.1893.060 ± 0.031122.293 ± 0.15449.965 ± 0.118196.077 ± 0.258115.836 ± 0.192197.922 ± 0.432131.757 ± 0.401224.569 ± 0.327138.881 ± 0.548253.095 ± 0.295179.739 ± 0.519304.351 ± 0.397228.875 ± 0.389396.117 ± 2.037316.573 ± 1.356551.046 ± 1.552487.610 ± 1.934144.861 ± 0.22065.845 ± 0.177226.178 ± 0.334135.478 ± 0.329260.228 ± 0.213161.769 ± 0.296279.380 ± 0.307193.212 ± 0.321327.282 ± 0.557241.633 ± 0.709408.249 ± 0.545318.136 ± 0.642526.307 ± 0.554441.163 ± 1.102766.677 ± 1.308658.538 ± 1.695182.301 ± 0.24577.630 ± 0.175272.785 ± 0.396161.470 ± 0.604313.002 ± 0.439195.466 ± 0.812392.977 ± 1.067265.163 ± 0.678449.671 ± 0.706346.768 ± 0.483549.557 ± 0.671439.445 ± 0.513701.312 ± 0.647593.615 ± 0.775960.017 ± 1.318857.253 ± 1.779270.091 ± 0.37298.874 ± 0.209391.446 ± 0.758209.299 ± 0.698442.482 ± 0.558277.086 ± 0.725542.029 ± 0.635369.562 ± 0.795699.364 ± 1.231489.296 ± 1.543794.251 ± 0.965626.974 ± 0.930983.273 ± 0.920804.285 ± 0.6781254.053 ± 1.8321066.830 ± 1.275445.825 ± 0.904129.738 ± 0.200641.263 ± 0.649289.152 ± 0.436713.181 ± 0.690372.448 ± 0.663830.807 ± 0.499487.805 ± 0.8431004.185 ± 1.122649.396 ± 0.7641237.963 ± 1.436895.591 ± 1.9371487.600 ± 1.1681145.585 ± 5.2101756.124 ± 2.2131396.981 ± 5.869839.912 ± 0.733165.206 ± 0.3371103.111 ± 1.202413.303 ± 0.5121222.819 ± 1.091530.356 ± 0.6531364.309 ± 1.599664.749 ± 0.7851548.493 ± 1.255865.435 ± 0.9661851.388 ± 1.4511159.547 ± 5.0382253.046 ± 8.1811534.134 ± 3.1982362.974 ± 2.4571705.116 ± 7.068874.147 ± 1.409166.424 ± 0.3741270.810 ± 2.079566.643 ± 0.6961469.561 ± 2.525742.514 ± 1.2071666.623 ± 2.374916.976 ± 1.3481859.909 ± 2.7111118.062 ± 1.5402219.444 ± 2.5261404.797 ± 2.3942439.326 ± 3.1401683.831 ± 7.4631941.294 ± 2.4601191.606 ± 1.200