RFR: 8291641: Optimize StackTraceElement.toString()
Quan Anh Mai
duke at openjdk.org
Mon Aug 1 17:31:43 UTC 2022
On Wed, 27 Jul 2022 22:56:39 GMT, David Schlosnagle <duke at 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
More information about the core-libs-dev
mailing list