[Issue 9584] Exceptions in D are ludicrously slow (far worse than Java)

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Feb 7 17:02:48 PST 2014


https://d.puremagic.com/issues/show_bug.cgi?id=9584



--- Comment #15 from Adam D. Ruppe <destructionator at gmail.com> 2014-02-07 17:02:32 PST ---
I just played with this a little. Regular set up: ~ 270ms for the exception.

Add  Runtime.traceHandler = null;, then run, down to about ~7ms per exception.

Then if I allocate the throwables on a separate buffer too
http://arsdnet.net/dcode/except.d it goes down to about ~4ms for a single
exception. (I expect this might make a bigger difference on really long running
things.)


But it is clear that the trace handler is much larger than the throwable
allocation.


Maybe we shouldn't do the stack trace on non-debug builds. Or at least
publicize the traceHandler line so people can opt-out of it.


As for doing it lazily, that would be a good idea, not sure if we can, but one
possibility might be to copy the callstack but NOT call backtrace_symbols until
the last possible moment. Replacing that function with a stub that just returns
null brings the time to 12 ms (all other things unchanged). That's a
significant improvement; 20x faster than the normal.


But, am I right that backtrace_symbols just needs the callstack thing? ...
which is a static array right here. Do we have to call backtrace_symbols in the
constructor?

hmmm apparently yes, I tried moving it, got a huge speed improvement (~10ms)...
but it segfaulted on an assertion failure after printing the stack trace....
but I think this is because of demangling rather than any intrinsic problem.

I'm still looking at it, but I think this might be fixable and can give a
significant improvement.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list