michael meeks <[EMAIL PROTECTED]> 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
