[Development] What kind of airplane we want to build?

Bogdan Vatra bogdan.vatra at kdab.com
Sat Jan 23 18:31:22 CET 2016


Hi,

As I promised, I did some benchmarks myself and I got some very surprising 
results.
The benchmark code is here: https://github.com/bog-dan-ro/exceptions_benchmark
The benchmark calls a function 1000000000 times and this function trows an 
exception/return an error every x calls (x = 100; x*=10). The noexcept 
function tries to mimic Qt's way to handle errors.

The results on desktop (intel i7) are here:  https://paste.kde.org/pbdedo4mw
gcc -O2 and -O3 gives the worst/random/surprising results. On the other hand, 
clang (to my HUGE surprise) gives the most consistent results. Even more 
surprising is the fact that in most/some cases the exception code produced by 
clang is faster :O !

The results on nvidia shield X1 are here: https://paste.kde.org/pz1leberi
The results even more surprising (the percentages are bigger).

Regarding the size overhead, I tested Qt(base) with&without exceptions (rtti 
seems enabled already) and the difference is only ~1Mb (23673504 with 
exceptions and 22584408 without), but because it doesn't use try/catch 
(almost?) anywhere, the size difference is pretty small (~5%). Then I found the 
following paragraph on 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html :
"Exception handling overhead can be measured in the size of the executable 
binary, and varies with the capabilities of the underlying operating system 
and specific configuration of the C++ compiler. On recent hardware with GNU 
system software of the same age, the combined code and data size overhead for 
enabling exception handling is around 7%. Of course, if code size is of 
singular concern than using the appropriate optimizer setting with exception 
handling enabled (ie, -Os -fexceptions) may save up to twice that, and 
preserve error checking."

So, if the size overhead of libstdc++ (which uses exceptions a LOT) is just 7% 
(+3.5% if we're using -Os), I'm pretty sure that Qt's overhead will be the 
same or even smaller.

Therefore, I see no reason not starting using exceptions in 6.0, or at least 
to think&discuss on this matter.

Cheers,
BogDan.

On Friday 22 January 2016 12:32:25 Bogdan Vatra wrote:
> On Friday 22 January 2016 10:55:34 Cristian Adam wrote:
> > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz <marc.mutz at kdab.com> wrote:
> > > I'm not sure about what outcome to expect, and I don't remember any
> > > numbers
> > > posted by anyone else, either.
> > 
> > From the David Stone's Writing Robust Code
> > <https://meetingcpp.com/tl_files/2014/talks/robust_code.pdf> page 34:
> > 
> > Performance of exceptions when not thrown
> > ● Tested on gcc 4.9.2
> > ● Numbers relative to ignoring errors
> > ● With no destructors
> > 
> >     – 12.8% overhead for exceptions
> >     – 32.8% overhead for return codes
> > 
> > ● With destructors
> > 
> >     – 6.3% overhead for exceptions
> >     – 18.7% overhead for return codes
> 
> Hmm, so, using exceptions makes your code 12-20% faster. This is a good
> thing, right?. Most probably the binary size will be slightly bigger, let's
> see if it's 12-20% bigger (my hunch is that it will not be more than 5%
> bigger). I'll do some tests this weekend and I'll share with you the
> results.
> 
> > And page 35:
> > 
> > Performance of exceptions when thrown
> > ● Tested on gcc 4.9.2
> > ● Numbers relative to ignoring errors
> > ● With no destructors
> > 
> >     – 900% overhead for exceptions
> > 
> > ● With destructors
> > 
> >     – 750% overhead
> 
> As I said, exceptions are like *a life vest*, they should be used *only in
> critical situations* not everywhere.
> 
> Cheers,
> BogDan.
> 
> P.S. Android Alexandrescu has a nice video on this matter:
> https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandr
> escu-Systematic-Error-Handling-in-C
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list