Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass()

Kasper Nielsen kasperni at
Wed Jul 3 05:22:47 UTC 2019

On Tue, 2 Jul 2019 at 22:49, Ralph Goers <ralph.goers at> wrote:
> The timing of this question is perfect. I have been doing some testing over the last week to address and found some interesting things - although they are related to the walk() method, not getCallerClass().

Getting a single stack frame with the calling class + line number for logging
is probably the most common use case for using a StackWalker.

I think optimized versions of these two methods would be really useful and
cover most of these usecases:

Optional<StackFrame> findFirstWithClassName(Predicate<? super String> p) {...}
Optional<StackFrame> findFirstWithDeclaringClass(Predicate<? super
Class<?>> p) {...}

There is really no reason to create a StackFrame object for every
frame. Only the final frame.

Perhaps even skip returning a StackFrame but just returning a string with
ClassName:Linenumber if there is significant overhead in creating the
StackFrame. I use StackWalker as well for logging, and find that the
2-3 microseconds it typically takes to get the calling class + line
number a bit steep in my performance budget.


More information about the core-libs-dev mailing list