Re: Poor exception handling performance

[Mears]

On Oct 27, 5:00 am, Jeff Schwab <j...@schwabcenter.com> wrote:
> 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.

I understand that exception handling is optimized for the case where
exceptions are not thrown, and CC did better than g++ in that area as
well, so it's not like CC cut corners to improve performance when
exceptions are thrown.  To me it seems like g++ could use some
improvement in this area.