Efficient UNO component linkage & GC ...

Stephan Bergmann sbergman at redhat.com
Mon Jan 6 07:45:58 PST 2014


On 12/23/2013 08:28 PM, Michael Meeks wrote:
> On Mon, 2013-12-23 at 18:44 +0100, Matúš Kukan wrote:
>>> * implementations of non-single-instance services can be rewritten using
>>> the new .component XML <implementation constructor="..." feature, cf.
>>> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae3a0c8da50b36db395984637f5ad74d3b4887bc>
>
> 	I'm concerned that we already have way too many, far too verbose XML
> files, with over-lengthy attributes (some with un-necessary and
> over-complicated namespacing to boot ;-). Parsing that lot takes a very
> considerable chunk of startup time, and storing redundant foo in memory
> seems a bit un-necessary :-)
>
> 	What does this:
>
>    <implementation name="com.sun.star.comp.graphic.GraphicRendererVCL"
> +  constructor="com_sun_star_comp_graphic_GraphicRendererVCL_get_implementation">
>       <service name="com.sun.star.graphic.GraphicRendererVCL"/>
>    </implementation>
>
> 	win us over:
>
>    <implementation name="com.sun.star.comp.graphic.GraphicRendererVCL" direct="1">
>       <service name="com.sun.star.graphic.GraphicRendererVCL"/>
>    </implementation>
>
> 	? :-) Certainly the latter can be stored as an extra boolean.

There is a mismatch between the grammar for UNO implementation names and 
C function identifiers usable for these constructor functions, and the 
constructor argument in its current form caters for that.

Note 1:  Of course, "given that we control the [relevant] impl names, we 
[could] simply mandate that they are legal C function names to begin with."

Note 2:  "In addition to having [the components data] 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."

Note 3:  A key insight is that "we can easily extend the components XML 
schema, even removing features again in a later LO version."  First make 
it work, then make it fast (if necessary).

Stephan


More information about the LibreOffice mailing list