Improving the performance of stacktrace generation

[Rémi Forax]

On 07/08/2012 12:50 AM, Charles Oliver Nutter wrote:
> On Saturday, July 7, 2012, Rémi Forax wrote:
>
>     You can use Throwable.getStackTraceElement()
>     which is package visible and OpenJDK specific but at least
>     it will be faster for all VMs that uses OpenJDK.
>
> I'll certainly explore that to see if it improves the situation. If 
> it's faster, it might be a way out in some circumstances.
>
> It seems like an official public API is needed here...
>
>         Please never optimize warnings, they are here to bug users
>
>     until they fix the thing. So they should be slow :)
>
>
> Yes, except when *everyone else* has faster warnings than you. Then 
> you're just giving people another reason to not use your stuff.
>
> Granted, JRuby is now becoming far and away the fastest Ruby 
> implementation for exactly the reasons that stack traces are slow, but 
> often making 90% of the code 5x faster but 10% of the code 100x slower 
> means people give up on you without bothering.
>
> Remember, I agree with you...but I also feel like this attitude has 
> allowed stack trace generation to avoid optimization effort for a long 
> time, and there *are* useful things you can do with an introspectable 
> call stack.

Throwable.getStackTraceElement() let you walk the stack trace without 
generating the whole stack trace,
in my opinion it's enough.

BTW, I also think you are responsible too for the cost of generating 
stacktraces because the cost depends on the size of the stacktrace
and an AST interpreter is a big consumer of stack frames. I am guilty 
too, PHP.reboot has the same issue and
I try to mitigate that by avoiding to have an helper methods in the 
stacktrace of calls (not that easy without tailcall).

>
> - Charlie

Rémi