Optimize metadata implementation by reducing type casts #1277
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.
Goal
Bugsnag's stores metadata using a nested
ConcurrentHashMap
. The implementation uses unnecessary type casts, which resulted in unnecessary calls toTypeIntrinsics.isMutableMap()
that added ~1ms for every ~10000 metadata values added.Changeset
Metadata was previously backed by
ConcurrentHashMap<String, Any>
. This has been changed toMutableMap<String, MutableMap<String, Any>>
.This more accurately reflects the metadata structure and has allowed for a net reduction in type casts throughout
Metadata.kt
. This has necessitated the addition of some type casts (mainly to maintain backwards compatibility with method signatures that should not change until the next major version).Testing
Relied on existing unit test coverage.
The performance impact of this change ended up being fairly minimal - typically
TypeIntrinstics
executed in <1ms, so its removal has a benefit around that amount. However, this still feels advantageous in that it simplifies the implementation and increases its type safety.