WIP remove lastScope field and deprecated implementations from SimpleObservation#7273
Draft
shakuzen wants to merge 1 commit into
Draft
WIP remove lastScope field and deprecated implementations from SimpleObservation#7273shakuzen wants to merge 1 commit into
shakuzen wants to merge 1 commit into
Conversation
06d0f8a to
e690f6b
Compare
This was referenced Mar 17, 2026
e690f6b to
82edf76
Compare
82edf76 to
11fe5d2
Compare
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
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.
This should not be merged until
mainis 1.18.0 snapshots.TODO: log warnings, update tests
This is a follow-up to #7255. With removing the
lastScopesfield onSimpleObservation, we avoid CPU cycles tracking info that is never used and we save memory perSimpleObservationinstance.JOL
We go from 40 bytes per instance to 32 bytes object overhead. See JOL output below. (with CompactObjectHeaders, it gets down to 24 bytes)
Previous JOL output
Benchmarks
We see allocation savings of 72 bytes per operation (explained by the object layout difference above and one less ConcurrentHashMap being instantiated). Note that is irrespective of the number of key-values used, so it will be a higher percent savings for Observations with less key-values.
This PR
1.17.0-M3