https://d.puremagic.com/issues/show_bug.cgi?id=9584
--- Comment #15 from Adam D. Ruppe <[email protected]> 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: -------
