Use bulk string writes for text formats #1273
Merged
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.
Further optimize
TextFormatUtil#writeEscapedLabelValue
. We're seeingTextFormatUtil#writeEscapedLabelValue
show up in our production traces due to the singlechar
writes toOutputStreamWriter
. We're usingOpenMetricsTextFormatWriter
. #1241 and #1248 should take care of most of these issues but there still remains some optimization potential left.BufferedWriter#write(int)
has some minimal overhead in terms of locking. If we assume that rarely any characters need to be escaped and instead optimize to write as large of a part of the String as possible in one method call.Before
After
About a 5% to 6% gain for
OpenMetricsTextFormatWriter
and around 3% forPrometheusTextFormatWriter
.Note that this benchmark is actually for
OpenMetricsTextFormatWriter
andPrometheusTextFormatWriter
sinceTextFormatUtil
is not public and can therefore not be benchmarked directly. The relative gains in#writeEscapedLabelValue
are higher because the benchmark runs the full text format writers.I also added a test for
TextFormatUtil#writeEscapedLabelValue
since the code is now more complicated.