Fix performance problems caused by Identifier#toHexString #615
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 addresses performance problems described in #612 where usage of beacon layouts with 3-15 byte identifiers results in slow calls to Identifier#toHexString, as this is what is used to convert identifiers of this length range to Strings.
Unfortunately, it is very difficult to remove the use of
toHexString()
in normal operation of the library, because it is used for both serialization ofBeacon
objects when moving them in the library, and for the implementation ofhashCode()
inBeacon
, which is heavily used for internal beacon tracking.Two changes:
Wrap two debug level logging calls to
beacon.toString()
in checks to see if verbose logging is enabled, so in normal cases, there will be no calltoString()
and hence no call totoHexString()
onIdentifier
.Optimize the implementation of
toHexString()
so it does not instantiate objects in a loop and instead uses primitive types for all conversion parts except the final construction of a single String object.The first change reduces the number of calls to
toHexString()
by 51%, with all the remaining calls being used for serialization and hashCode calculations.The second change improves the performance of the method by 90% from 240 microseconds per call to 23 microseconds per call on a Nexus 5X.
Between these two changes, processing time in toHexString() is reduced by 95%, and the number of objects allocated is sharply reduced.