Draft
Conversation
Numeric metric values were formatted using specialized number format that truncated values to 6 fractional digits and did not use exponential format for larger numbers. While it slightly reduces number of transmitted bytes for fractional numbers close zero, it is less efficient for larger values. A micro-benchmark also shows that not using NumberFormat is generally much faster. These numbers are from JDK 11, but the numbers are similar for JDK 8 and 25. Benchmark (value) Mode Cnt Score Error Units FullPrecisionBenchmark.format_default 3.141592653589793 thrpt 10 3.035 ± 0.182 ops/us FullPrecisionBenchmark.format_default 3.3E20 thrpt 10 3.465 ± 0.764 ops/us FullPrecisionBenchmark.format_default 42.0 thrpt 10 5.711 ± 1.908 ops/us FullPrecisionBenchmark.format_default 0.423 thrpt 10 4.977 ± 1.437 ops/us FullPrecisionBenchmark.format_default 243.5 thrpt 10 4.871 ± 0.232 ops/us FullPrecisionBenchmark.format_full_precision 3.141592653589793 thrpt 10 5.888 ± 0.411 ops/us FullPrecisionBenchmark.format_full_precision 3.3E20 thrpt 10 20.946 ± 0.681 ops/us FullPrecisionBenchmark.format_full_precision 42.0 thrpt 10 33.849 ± 0.391 ops/us FullPrecisionBenchmark.format_full_precision 0.423 thrpt 10 23.927 ± 0.685 ops/us FullPrecisionBenchmark.format_full_precision 243.5 thrpt 10 16.318 ± 0.777 ops/us This brings brings client behavior closer to that of other clients: Python uses built-in str() conversion which will use exponential format for large numbers, and Go, which, while doesn't use exponential format, does not truncate precision (on most metrics at least). All agent versions and ADP/Saluki are able to handle this format. An option is added to restore legacy behavior in case this causes any compatibility issues.
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
1 participant
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.
Numeric metric values were formatted using specialized number format that truncated values to 6 fractional digits and did not use exponential format for larger numbers. While it slightly reduces number of transmitted bytes for fractional numbers close zero, it is less efficient for larger values.
A micro-benchmark also shows that not using NumberFormat is generally much faster. These numbers are from JDK 11, but the numbers are similar for JDK 8 and 25.
This brings brings client behavior closer to that of other clients: Python uses built-in
str()conversion which will use exponential format for large numbers, and Go, which, while doesn't use exponential format, does not truncate precision (on most metrics at least).All agent versions and ADP/Saluki are able to handle this format. An option is added to restore legacy behavior in case this causes any compatibility issues.