Hi there,
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
Hi Giovanni,
On Sat, 2005-07-30 at 15:36 +0200, Giovanni Bajo wrote:
> I'm slow, but I can't understand why a careful design of the interfaces of
> the dynamic libraries
Well - sure, depends how 'careful' you are ;-) clearly if no C++
classes with virtual methods form the interface of any
On Sat, 2005-07-30 at 18:25 +0100, Andrew Haley wrote:
> > > 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
>
> One thing I don't understand is the formula w
Hi Dan,
On Sat, 2005-07-30 at 11:19 -0400, [EMAIL PROTECTED] wrote:
> MM wrote in http://go-oo.org/~michael/OOoStartup.pdf:
> "... not one slot was overridden by an implementation
> method external to the implementing library."
This is really an issue rather orthogonal to that of 'final',
On Mon, 2005-08-01 at 14:18 +0200, Steven Bosscher wrote:
> On Monday 01 August 2005 11:44, michael meeks wrote:
> > However - the log(s) term is rather irrelevant to my argument :-)
>
> Not really. Maybe the oprofile results for the linker show that the
> behavior is wors
Hi H.J.,
On Mon, 2005-08-01 at 08:55 -0700, H. J. Lu wrote:
> > -fvisibility is helpful - as the paper says, not as helpful as the old
> > -Bsymbolic (or link maps exposing only 3 or so functions) were. However
> > - -fvisibility can only help so much - if you have:
>
> Since you were comparin
On Tue, 2005-08-02 at 06:57 -0700, H. J. Lu wrote:
> Maitaining a C++ linker map isn't easy. I think gcc should help out
> here.
What do you suggest ? - something separate from the visibility markup ?
perhaps what I'm suggesting is some horribly mis-use of that. Clearly
adding a new visib
Hi Jakub,
On Mon, 2015-08-24 at 10:17 +0200, Jakub Jelinek wrote:
> > Jakub: How about using git bisect instead, and identify the compiler
> > binaries with the git commit sha1?
>
> That is really not useful. While you speed it bisection somewhat by avoiding
> network traffic and communication w
On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
> While PR53646 claims that c++98 and c++11 should be ABI
> compatible (modulo bugs), the addition of the _M_size member
> to std::_List_base::_List_impl makes libraries using
> std::list in headers incompatible
This is pretty nasty
Hi guys,
I spent a little time recently researching ways to reduce the number of
unique named relocations that must be processed at dlopen time for large
C++ libraries[1]. Apologies for spamming all 3 lists like this, but it
touches all 3 projects.
Since almost all function reloca
Hi Ian / Andi,
On Wed, 2008-04-02 at 07:56 -0700, Ian Lance Taylor wrote:
> * Use GNU instead of SUSE, as this is for the GNU tools.
Ah yes; you noticed the subliminal advertising ;-) If you're happy for
me to trample on the GNU section namespace that's fine, but I hesitate
to tread there
11 matches
Mail list logo
