Performance: Getting rid of temporary internal StringWriter #1298
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.
TL;DR: This PR internally optimizes the JAX-RS API implementation code by getting rid of
StringWriter
for purely temporary use case.Requesting fast-track according to our Committer Conventions, as this PR is a non-API, non-spec, non-javadoc change.
For those interested in the details:
StringWriter
is implicitly synchronized due to its internal use ofStringBuffer
, whileStringBuilder
is non-synchronized. Using synchronized code in single-threaded contexts is not needed.append
thanks to bigger upfront buffer allocation.null
automatically appends"null"
. This is implied byStringBuilder
, no need for custom code.char
is faster than adding a single-characterString
.StringBuilder
has fluent API; no need to repeatsb
again and again.String +
operation implies creation ofStringBuilder
, and is proven to be always faster than an explicitStringBuilder
(see Video "String Concatenation - JEP Café #7" for the benchmark results).String +
operator is indified, leading to higher performance in future, just by upgrading JRE.