On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle <d...@openjdk.org> wrote:
> I would like to contribute an optimized version of > `StackTraceElement#toString()` that uses a single StringBuilder throughout > creation to avoid intermediate `String` allocations. > `StackTraceElement#toString()` is used in a number of JDK code paths > including `Throwable#printStackTrace()`, as well as many JDK consumers may > transform `StackTraceElement` `toString()` in logging frameworks capturing > throwables and exceptions, and diagnostics performing dumps. > > Given this usage and some observed JFR profiles from production services, I'd > like to reduce the intermediate allocations to reduce CPU pressure in these > circumstances. I have added a couple benchmarks for a sample > `Throwable#printStackTrace()` converted to String via `StringWriter` and > individual `StackTraceElement` `toString`. The former shows ~15% improvement, > while the latter shows ~40% improvement. > > Before > > Benchmark Mode Cnt Score Error > Units > StackTraceElementBench.printStackTrace avgt 15 167147.066 ± 4260.521 > ns/op > StackTraceElementBench.toString avgt 15 132.781 ± 2.095 > ns/op > > > After > > Benchmark Mode Cnt Score Error > Units > StackTraceElementBench.printStackTrace avgt 15 142909.133 ± 2290.720 > ns/op > StackTraceElementBench.toString avgt 15 78.939 ± 0.469 > ns/op If the objective of this patch is to optimise `StackTraceElement::toString()`, then I would suggest the most efficient method of calculating the length and encoding of the result, filling the backing buffer then using the package-private constructor of `java.lang.String` to construct the final result. And if you want to propose exposing `StackTraceElement::appendTo(Appendable)`, then I think it should be a separate patch instead. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9665
