Performance of exception handling

Sean Kelly sean at invisibleduck.org
Tue Apr 26 11:55:24 PDT 2011


On Apr 26, 2011, at 11:39 AM, Steven Schveighoffer wrote:

> On Tue, 26 Apr 2011 14:26:00 -0400, Sean Kelly <sean at invisibleduck.org> wrote:
> 
>> On Apr 26, 2011, at 9:29 AM, Denis Koroskin wrote:
>> 
>>> On Tue, 26 Apr 2011 20:14:05 +0400, Sean Kelly <sean at invisibleduck.org> wrote:
>>> 
>>>> Right now, traces are generated on throw. It should be possible to generate them on catch instead. The performance would be the same either way however. It would be nice to generate them lazily but I don't think that's possible.
> 
> If it's possible to generate them on catch, couldn't you request trace generation while inside the catch block (or at the beginning of a catch block) if you intend to use it?
> 
> That is:
> 
> try
> {
>   ...
> }
> catch(Exception e)
> {
>   e.generateTrace(); // only allowed at the start of the catch block
>   printException(e); // if you haven't generated the trace by now, it's gone.
> }
> 
> You'd need compiler help for this probably.  But I agree with the OP, 99% of the time you are catching exceptions you do not need the trace.

I suppose it's a matter of how easy this stuff should be to use.  I generally like the default behavior to be the most foolproof.


>>> Interesting enough, it is already done lazily (in toString(), which I believe should also cache result when it's called first time), but it can be improved a bit.
>> 
>> The readable version is generated in toString, but the actual trace occurs on throw.  This pretty much requires a memory allocation to store the trace info, which is one cause for the performance hit.
> 
> I can't help but think that using the GC may be overkill here.  At the very least, you can use C malloc which is usually much faster.  The exception should encapsulate the memory allocation and deallocation completely.

The DefaultTraceInfo object is allocated via the GC, and the trace info itself is allocated via malloc() inside the backtrace() call.  See core.runtime for the details--the code is pretty succinct.


More information about the Digitalmars-d mailing list