Efficient UNO component linkage & GC ...

Stephan Bergmann sbergman at redhat.com
Fri Dec 13 02:36:19 PST 2013


On 12/12/2013 02:47 PM, Michael Meeks wrote:
>> 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.

To be clear, this is about source files, not installation-/run-time ones.

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

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

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).

Stephan


More information about the LibreOffice mailing list