TITLE: static and dynamic cost of exceptions

(Newsgroups: comp.lang.c++.moderated, 8 Nov 96)

VANDEV: vandevod@cs.rpi.edu (David Vandevoorde)

> >> This is true... but `no overhead' does not imply `no cost': even the
> >> `no overhead implementations' seem to disable or hinder certain (IMO,
> >> important) optimizations.


LEONARD: Bill Leonard <bill@amber.ssd.csd.harris.com>

> BL> But that's not a *necessary* result.  Let's be clear about what we're
> BL> talking about, though.


VANDEV:

> I don't deny it, but I haven't seen a proof of it either. Have you?

BALL: michael.ball@Eng.Sun.COM (Mike Ball)

Exception handling provides additional possible control flow paths.  This
is inherent in the definition.

In our own compiler, no optimizations are disabled because of
exception handling.  The additional control paths are handled just
like all others, and can sometimes cause extended variable lifetimes,
as well as making some otherwise feasable optimizations more difficult
or impossible.  This is inherent in the semantics of exceptions.

If there are tests for return values at these points, these
conditional transfers will cause similar control paths and will have
similar effects on optimization.  Using exceptions has the advantage
that the rarely executed exception handling code can be moved out of
line, reducing cache and paging overhead.  Unfortunately, we do not do
that in our currently shipping compilers, so don't bother looking for
it.

There is a slight measured loss in performance for code compiled with
exceptions enabled, ranging from 0 to about 4%.  If there are no
destructors for local objects, as well as no try/catch blocks, the
cost is 0.  The additional cost in other cases seems to come from
additional register pressure due extended variable lifetimes and from
cache pressure from the exception handling code.  We have not done the
research to provide more precise results, so this explanation may turn
out to be incorrect.

We have not tried it on heavily numeric code, so I have no data on tha.

VANDEV:

> Again, I don't deny this, but I haven't seen C++ compilers (or a proof
> of feasibility) which optimize as aggressively in the presence of
> exceptions as they do when exceptions are disabled (and delayed error
> handling techniques are applied instead).

BALL:

See above.  Our compiler is every bit as aggressive with exceptions enabled,
there is just a bit more to do.

VANDEV:

> I would be very interested in any theoretical or practical reports in
> this area (or references thereto).

BALL:

I wish we could give you some references.  Perhaps in the future.  We have
an employee who is interested in the questions, but we haven't given her
time to do the work :-(