Re: Efficient UNO component linkage & GC ...

On Fri, 2013-12-13 at 11:36 +0100, Stephan Bergmann wrote:
> To be clear, this is about source files, not installation-/run-time ones.

        Sure - but even so - there are a lot of components ;-)

        xmllint --format services.rdb | grep '<implementation' | wc -l
        1019
        git ls-files | grep '\.component' | wc -l
        270

        I'd prefer not to add (and maintain) another 700 tiny files to git that
are mostly headers; or did I miss the suggestion ?

        I guess until we have mergedlibs on Windows, we can't easily dispense
with the .component files for internal components and just build an
internal data-structure. Even if we did, I imagine compiling /
generating that from .component files might be more interesting &
elegant anyway.

> > > 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.
>
> I'd assume the major size savings would come from leaving out unused 
> areas of code, and that would already be possible without the "go 
> further" part.

        True - but while we're here - AFAICS we should go further to clean that
up & make it more efficient =) it's a golden opportunity I think.

> The duplication is an unfortunate consequence of the move from active to 
> passive component registration.  And as the code was already there, I 
> never bothered too much to change that to instead re-use the .rdb data. 
>   (Which wouldn't have been easy or elegant, but that might be different 
> if we represent the .rdb data not in an additional file read at start-up 
> but in some compiled-in data structures).

        Yes - it's a great idea. I love it as an iteration - not least because
it should/could kill all that horrible native-code.cxx duplication =)
Then again it's quite nice to be able to build multiple binaries with
different component sets included from the tree - so I guess having some
form of run-time registration of some nice const static component
descriptions would be cool.

        Anyhow - looking forward to what Matus comes up with =)

        Regards,

                Michael.

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