Help: Unwinding the C++ stack...throw, longjmp & threads
George T. Talbot
george@moberg.com
Tue Aug 24 14:18:00 GMT 1999
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>
More information about the Libc-alpha
mailing list