Improve performance of getOperationName #16
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.
I recently performance load test on an application using the java interceptor to send traces to Jaeger.
Inside a performance profile, I saw a high cost (3% total CPU cost, but more than 60% of span creation+start+finish time) for the
getOperationMethod
due to the usage of a StringFormatter.I did some small experiment with JHM, and using a StringBuilder with an initial capacity seems a better option (10x quicker). As creating span occurs in the hot path of an application, I think it's a good thing to remove this hotspot.
I try several approach, this seems to be the better. We can go with simple string concatenation if the code seems too complex, as since Java 9 (and the string concatenation improvement) it is as performant as using a StringBuilder.
Here is my JMH benchmark
And the result on my laptop (Linux - Java 11 - 6 cores)