Re: Large, modular C++ application performance ...

[michael meeks <michael dot meeks at novell dot com>]

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 library, then
there is no problem ;-) unfortunately, mandating that would rather
cripple C++.

>  together with the new -fvisibility flags, should not
> be sufficient. It worked well in other scenarios

	-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:

class LibraryAClass {
	virtual void doFoo(void);
};
class LibraryBClass : public LibraryAClass {
	virtual void doBaa(void);
};

	then there are 2 problems:

	a) there is no symbol visibility that will trigger internal
	   binding in addition to a symbol export. ie. if 
	   'LibraryBClass' is a public interface - no useful
	   visibility markup can be done; and hence we have a named
	   relocation for 'doBaa's vtable slot.
	   [ IMHO this is a feature-gap, we need a new ('export'?)
	     visibility attribute for this case ].

	b) even if LibraryBClass is a 'hidden' class - to build it's
	   vtable we have to have a slot for 'doFoo' which is in
	   an external library (A) => another named relocation. An 
	   unavoidable consequence of using virtual classes as part of
	   a library's API.

> IMHO, it's unreasonable to break the C++ ABI for 1 second of warm time
> startup.

	Well - it's an option that was considered, although - as you say -
highly unpleasant, and probably quite unnecessary - as the paper
explains.

	Regards,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot