[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:13:11 PST 2014


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


Adam D. Ruppe <destructionator at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator at gmail.com


--- Comment #16 from Adam D. Ruppe <destructionator at gmail.com> 2014-02-07 17:13:03 PST ---
I got it kinda working, though I included one bit of a hack (I'm not sure if
this is right or not, I don't fully understand why that assertion is there in
the first place, but I figured if it was going to trigger, just return without
demangling. Seems to give the same output as the regular handler.)

Relevant code is at the bottom:

http://arsdnet.net/dcode/except2.d


I copy/pasted the trace handler from druntime then hacked it up so
backtrace_symbols is called in the opApply rather than the ctor. This also
meant moving the symbol list from a local variable to a class member and
freeing the memory with a local scope guard instead of the dtor. Then hacked
around the failing assert (line 291).

Chained exceptions still work. Demangling still works. Backtraces still printed
on toString. We could perhaps cache the result of the symbol getter btw, I
didn't here primarily because opApply is a const method so that'd mean casting
away this const (the whole logical const caching issue lol). But who calls
toString more than once on an exception anyway? So meh I don't think it
matters. Besides I'd rather that be slow than the typical throw+catch pair
being slow.


Also I'm on Linux so idk if this will be better on other systems but it looks
to me like the other OSes share this code so maybe it will rock there.

but yeah I think lazy backtrace is a win. test plz

-- 
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