Lazily initiate guid on DefaultTracer #2057
Closed
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.
Before contributing, please read our contributing guidelines and code of conduct.
Overview
I was doing some flame graph analysis and noticed that every tracer had a guid created. However, it would appear that the guid is only really needed on demand if the trace is being reported on.
Here are the flame/icicle graphs of memory allocations from a simple Spring webflux app. Note the number of instances with byte[], char[], String, and DefaultTracer are most allocated.
Unrelated (for a different issue), the reactive streams instrumentation on spring boot creates an gigantic number of tracers. I'm thinking of ways to maybe cut down on that. Or maybe DefaultTracer/AbstractTracer could be make lighter (there are a lot of fields).
NOTE: does this need to be thread safe? I could add a lock or CAS, if you want.
Related Github Issue
none
Testing
Normal CI suite should pass. If you run flame chart analysis the additional memory allocations should disappear.
Checks