Re: Efficient UNO component linkage & GC ...

Hi Stephan,

        Thanks for the review ! Matus should start work on this shortly.

On Fri, 2013-10-11 at 17:20 +0200, Stephan Bergmann wrote:
> DllComponentLoader is mostly dead by now, only comes into play during 
...
> Handling of the prefix feature is done entirely in 
> cppuhelper/source/servicemanger.cxx and cppu::loadSharedLibComponentFactory.

        Ah right my bad; as you say we should add this here: 

> To split into smaller,  unconnected parts would mean to split existing
> <component> XML entities into smaller ones, each with its own prefix 

        That would suck IMHO :-) we have enough scattered files.

> Or, as you detail below, go further and add more efficient support for 
> the "single-object-implementation" factory case.  (Do you have any idea 
> whether this is worth it, given we have to continue supporting the other 
> case for extension-compatibility anyway?)

        Sure it's worth it given we're primarily looking for size savings for
mobile; for the Linux case we get only marginal wins here I think.

> Anyway, given that the current "prefix" feature should only be used by 
> internal code we have under full control (see recent discussion 
> elsewhere on this mailing list), should we go down that road, I'd prefer 
> to replace the existing "prefix" feature with something new (e.g., an 
> extension of the components XML schema that associates an individual 
> <implementation> rather than a <component> with a prefix attribute), 
> rather than keeping both.  (Though we could support both for a 
> transition period while we incrementally update the existing code.)

        Yep - agreed; it's nice we're flexible here, just some inevitable
transition period where we'd try the direct symbol approach, and then
fallback to the old prefix'd factory function.

> What would likely be more entertaining is to get rid of the 
> cppu::createSingleFactory layer of indirection.  (As you come to in part 
> three.  But note that there are service implementations that rather act 
> like singletons and always hand out the same object instance; that needs 
> to be taken care of.)

        Yes - hopefully that's easily done. Luckily it's all internal, was just
chatting with Matus and considering the symbol could point to a C struct
easily enough something like:

extern "C" struct {
        const char            *pImplementationName;
        ComponentInstantiation pCreateFunction
        const char            *pServiceNames[];
} ComponentEntryPoint;

        And have some wrappers to help with converting the ComponentEntryPoint
record into the results we want from the XServiceInfo methods
(getSupportedServiceNames etc.)

> An alternative is to extend the components XML schema to support lookup 
> of the factory function directly in the executable (say) rather than a 
> given dynamic library (e.g., by having a local="true" attribute rather 
> than a uri="..." one).  Since the uri attributes are already inserted 
> into the .component XML files at build-time, it shouldn't be too hard to 
> combine that with a configurable list of components that end up directly 
> linked into the executable.

        Interesting idea. I'd like to see how this shakes out in a few
iterations here I think. I agree that we're going to need something
like:

 <component loader="com.sun.star.loader.SharedLibrary" prefix="svx"
    xmlns="http://openoffice.org/2010/uno-components";>
- <implementation name="com.sun.star.comp.Draw.GraphicExporter">
+ <implementation name="com.sun.star.comp.Draw.GraphicExporter" direct="true">
    <service name="com.sun.star.drawing.GraphicExportFilter"/>
  </implementation>
  <implementation name="com.sun.star.comp.Svx.GraphicExportHelper">
    <service name="com.sun.star.document.BinaryStreamResolver"/>
    <service name="com.sun.star.document.GraphicObjectResolver"/>
  </implementation>

        Incidentally - do we actually use the service information in anger ?
ie. could we not populate / store the data required for the XServiceInfo
interface from the services.rdb at run-time, rather than having it
duplicated in the code ? or is there some benefit to that ?

> In addition to having them stored as XML files that are parsed at start-up in 
> cppuhelper::ServiceManager::init, one could optionally have them 
> pre-compiled into some data structure that is accessible from 
> cppuhelper/source/servicemanager.cxx.  In which case the data structures 
> for such local="true" components could directly contain function 
> pointers to the corresponding factories.

        Very true =) perhaps that would get rid of the whole native-code.cxx
mess as well - centralizing it and making it fully generic - that would
be nice.

> > * Part three - faster component instantiation
> >
> >     The wonderful work Noel has been doing around more beautiful
> > ways to instantiate components should dove-tail with this nicely.
...
> >     Which should be much smaller and neater.
>
> Question is how much that "much" would actually be.  (And one would have 
> to generate two variants of service/singleton C++ headers, an optimized 
> one for internal use and a traditional one for external use.)

        Well if we call directly into the method that instantiates the object,
then LTO can potentially start to inline a lot of things and ignore a
lot of exceptions that we know are not thrown etc. presumably it may
have some benefits for a merged-libs case.

        Anyhow - thanks for the feedback - moving ahead here soon (I hope) on
master.

        ATB,

                Michael.

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