Re: TRY/CATCH is unnecessarily slow on OS X

["Lorenz Minder" <lminder@gmx.net>]

Hi Bill,

BA:
> On Thu, Sep 03, 2009 at 08:43:44AM +0200, Lorenz Minder wrote:
> > Below are a number of measurements.  Summary:
> > 
> > * Cost setjmp vs no error checking:
> > 	Mac OS:	12x (32 bit)	4.5x (64 bit)
> > 	NetBSD:			2.5x (64 bit)
> > 	Linux:	+32% (G4)
> > 
> > * Cost _setjmp vs no error checking:
> > 	Mac OS:	+21% (32 bit)	+21% (64 bit)
> > 	NetBSD:			+17% (64 bit)
> > 	Linux:	+34% (G4)
> > 
> > * C++ EH seems to cost somewhere between nothing and 8%.  (But the
> >  library size goes up by ~10%.)
> 
> But what is the performance penaly on the overall library (outside
> exception) ?

Good point.  I had assumed it would not make any difference, because 
it shouldn't.  But it would obviously be foolish not to test.

I did 'make test-all' with versions compiled with -fexceptions, without
that flag, and also with -fno-exceptions, just for good measure.  The
differences I see are in the range of promilles at most, and not always
in favor of -fno-exceptions.  The differences are most likely just noise.

OS X, i386 (tests using data packages bailed out).
    (no added cflag) gp-sta = 284206            gp-dyn = 286990
w/  -fexceptions     gp-sta = 284941 (+0.26%)   gp-dyn = 287204 (+0.07%)

NetBSD, amd64 (all tests running, resultant fails).
w/  -fno-exceptions  gp-sta = 248517            gp-dyn = 252819
    (no added cflag) gp-sta = 248480 (-0.01%)   gp-dyn = 252704 (-0.05%)
w/  -fexceptions     gp-sta = 247763 (-0.1%)    gp-dyn = 252854 (+0.01%)

Obviously the differences static vs dynamic are much larger than the
-fexception differences.

I should mention that the I patched TIMER() on NetBSD, so as to fix
the problem of the erratic negative and high variance time measurements
I saw.  I have attached that patch for transparency.

> now I found something about 
> 
>   Linux Core2 6600 (64bit) : +20%
>   Linux Core2T5500 (64bit) : +18%
>   Linux Opteron(64bit): +14% 
> 
> So this confirms that the slowdown is around 20% as you said.

Great.  This looks very acceptable.

I guess the question now is:  Given that TRY/CATCH is meant only for
internal use, and that a different error handling mechanism is under way,
do you think the number of uses of those macros in libpari warrant a patch
that uses _setjmp() when possible?

Best,
--Lorenz
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Attachment: timer.patch
Description: Binary data