Re: Poor exception handling performance

[Jeff Schwab]

On Oct 26, 9:49 pm, Mears <joshuadavid...@gmail.com> wrote:
> I spent some time profiling exception performance on Solaris 10 with
> Sun's CC and two different versions of g++.  The setup was a class
> that threw an exception (an int value) in its constructor if an
> argument was out of range.  The main program basically dynamically
> allocated objects of that type a variable number of times.  I tested
> three different scenarios:
>
> 1.  Exception not thrown, and no try/catch in the main program
> 2.  Exception not thrown, and a try/catch surrounding the "new"
> statement.
> 3.  Exception thrown, and a try/catch surrounding the "new" statement
> (catch was a no-op).
>
> The compilers I used were (information from version options):
> CC - Sun C++ 5.8 Patch 121017-10 2007/02/21
> g++ - 3.4.3 (csl-sol210-3_4-brach+sol_rpath)
> g++ - 2.95.3 20010315 (release)
>
> The performance of g++ when not throwing an exception (scenarios 1 &
> 2) was acceptable IMO.  CC definitely had an edge, but all were
> quick.  However, when I started testing scenario 3, g++ was
> horrendous.  For example , when calling the constructor 1,000,000
> times (and thus throwing 1,000,000 exceptions), on average CC
> completed the test program in 2.3 seconds, g++ 2.95.3 completed in
> 15.9 seconds, and g++ v3.4.3 completed in 22.1 seconds.  I was
> extremely surprised to see g++ nearly 10 times slower at handling
> throw statements than CC, especially since it was much closer with
> exception overhead when not throwing.

That is the intent.  Typical exception (forgive the oxymoron) support
is heavily optimized for the case in which exceptions are not thrown,
because that case should be much more common.  The point is that your
program isn't penalized for being robust.  If something actually goes
wrong, the call stack should be unwound to the point where an
appropriate handler can address the problem.  This isn't something
that should be happening repeatedly in a loop.