In <6p03k3$cb8@engnews1.Eng.Sun.COM> stephen.clamage@sun.com (Steve Clamage) writes:
>
> In <2NAs1.1282$AI4.4123271@ptah.visi.com> jstern@citilink.com (Josh Stern) writes:
>>
>>Since the de facto topic of this thread is code bloat
>>in C++ and its relationship to quality of implementation,
>>I'd like to ask about how much (if any) efficiency is gained
>>with existing C++ compilers when throw() is added to
>>all function definitions where it is permissible to add it.

A paper I wrote concerning this and related subjects is in the August
1998 ACM SIGPLAN Notices:  "Optimizing Away C++ Exception Handling".
It measures the SCO C++ compiler against a bunch of public domain C++
benchmarks and source codes.

>We [Sun] have done some measurement of some
>programs compiled with exceptions disabled and again with
>exceptions enabled. When exceptions are enabled, the
>total program size increases by about 10 to 15 percent.

We found with the SCO compiler that program size increases due to EH
tend to vary a lot depending upon the application, with a cluster
of results showing essentially no increase, another cluster around
a 5-7% increase, and another cluster around a 20% increase.  I guess
that's sort of consistent with Sun's results :-)  The size increases
in particular get worse if EH-specific optimizations aren't done.

There is also an execution time increase due to indirect optimization
loss, that is generally 0..5% (Sun's results may be better if they've
done more work in the back end to compensate for this).

>The [Sun] compiler does take notice of empty throw-specifications,
>and omits generating code to deal with exceptions that
>cannot occur. Of course, the function with an empty
>throw specification needs extra code to be sure no
>exceptions escape, but if that function contains nothing
>that can throw an exception, that extra code is also omitted.
>[...] I don't have figures for selective use of empty throw
>specifications.

The SCO compiler also does this kind of optimization, i.e. omitting
EH tables when an upward-propagating scan of function source and/or
the presence of throw() specifications can establish that a function
doesn't need them.  None of the public domain sources that I could
find used exception specifications, so instead I instrumented the
sources to put them everywhere (see paper for details).

The results of this vary again depending upon the application; some
do better with the throw()'s, in fact approaching the times for EH
being suppressed altogether, while some do worse (in both directions,
the change is <= 10%).  What the paper also shows is that if the
compiler does *not* have empty throw specification optimization
(as Sun and SCO do), then the results can be disastrous: execution
times and program sizes can go up by factors of two and three.  This
is because you'll be triggering EH table generation and indirect
optimization loss everywhere.

So I think the bottom line is: adding throw()'s can help with some
applications, but make sure your compiler is optimizing based on
them first.

--
Jonathan Schilling              SCO, Inc.               jls@sco.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <199809220222.WAA09741@kauai.newjersey.sco.com>, Jonathan
Schilling <jls@sco.com> writes
>So I think the bottom line is: adding throw()'s can help with some
>applications, but make sure your compiler is optimizing based on
>them first.

Thanks for the info.  I think that we need to have a major campaign with
implementors to support throw() optimisations because without it we have
a serious problem in writing efficient portable code.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]