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
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
