This is the mail archive of the
mailing list for the GCC project.
Re: [I don't think it's off-topic at all] Linking speed for C++
- To: geoffk at geoffk dot org (Geoff Keating)
- Subject: Re: [I don't think it's off-topic at all] Linking speed for C++
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Wed, 9 May 2001 17:04:47 -0700 (PDT)
- Cc: jsturm at one-point dot com (Jeff Sturm), gcc at gcc dot gnu dot org
> Jeff Sturm <firstname.lastname@example.org> writes:
> > For C++ I'm not sure what you can do, especially in the constraints of an
> > ABI. Perhaps the vtable entries could initially point to a private
> > function that would lazily find the appropriate method and write the
> > address to the vtable slot? I have no idea if that would be of any
> > benefit.
Geoff Keating writes:
> That's likely to cause problem with comparing pointers to methods.
Besides, if the pages get modified on the fly they can't be shared.
The KDE user is going to have maybe 20 processes all using -lqt and the
basic KDE libraries, with lots of vtables in them, probably hundreds
of K worth. Currently the runtime relocations prevent them from being
shared, but if they can be shared, that recovers a substantial amount
of memory (which then could be used up again with stubs or something