Re: Help: Unwinding the C++ stack...throw, longjmp & threads

["George T. Talbot" <george@moberg.com>]

Ulrich Drepper wrote:
> 
> "George T. Talbot" <george@moberg.com> writes:
> 
> > I don't know.  Mr. Drepper, can you tell us what was measured?  Was this
> > with the new exception model or the old setjmp()/longjmp() exception
> > model?
> 
> I don't remember.  One of the things which was measured for sure is
> code/data size and this went up.

My apologies if this is a duplicate.

I patched glibc 2.1.1pre2 so that it's compiled with -fexceptions.  This
increased the size of libc.so from 1.2M to 1.4M.  Is this size increase
acceptable for a change to the mainline distribution?  I don't have the
experience with the customers of glibc to assess that.

How would I go about measuring the performance penalty of -fexceptions
in
normal C code?  When I install the recompiled library, everything seems
to
be the same, and compiles seem to take the same amount of time.  I will
measure a large compile (maybe the kernel or something) and post to the
lists when I've done so.

I noticed that the testsuite directory is empty with a notice about
copyright/patent issues.  Would I measure performance with the
testsuite?
Is there another method you would prefer I use?

What would be the cutoff at which a change wouldn't be accepted into a
mainline distribution with respect to the performance impact of
-fexceptions?

In other words, at what point does the performance penalty of
-fexceptions
become unacceptable and how do I measure it?

P.S.:  I'm using egcs 1.1.2 to compile the C library right now, as
that's
what the configure script wants.  When I get a version of the C library
that can be compiled with gcc 2.95.1, I can try that, too.
--
George T. Talbot
<george@moberg.com>