This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Large, modular C++ application performance ...
- From: "Giovanni Bajo" <rasky at develer dot com>
- To: <michael dot meeks at novell dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Sat, 30 Jul 2005 15:36:14 +0200
- Subject: Re: Large, modular C++ application performance ...
- References: <1122666555.19624.25.camel@linux.site>
michael meeks <michael.meeks@novell.com> wrote:
> I've been doing a little thinking about how to improve OO.o startup
> performance recently; and - well, relocation processing happens to be
> the single, biggest thing that most tools flag.
>
> Anyhow - so I wrote up the problem, and a couple of potential
> solutions / extensions / workarounds, and - being of a generally
> clueless nature, was hoping to solicit instruction from those of a more
> enlightened disposition.
>
> All input much appreciated; no doubt my terminology is irritatingly up
> the creek, hopefully the sentiment will win through.
>
> http://go-oo.org/~michael/OOoStartup.pdf
>
> Two solutions are proposed - there are almost certainly more that I'm
> not thinking of. I'm interested in people's views as to which approach
> is best. So far the constructor hook approach seems to be the path of
> least resistance.
I'm slow, but I can't understand why a careful design of the interfaces of
the dynamic libraries, together with the new -fvisibility flags, should not
be sufficient. It worked well in other scenarios
(http://gcc.gnu.org/wiki/Visibility).
IMHO, it's unreasonable to break the C++ ABI for 1 second of warm time
startup.
--
Giovanni Bajo