Efficient UNO component linkage & GC ...

[Michael Meeks]

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 at collabora.com  <><, Pseudo Engineer, itinerant idiot