Efficient UNO component linkage & GC ...

[Michael Meeks]

Hi Stephan,

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.

	Given that we can trivially produce the symbol name from the
implementation name at run-time ? [ if we even need to produce it at all
- since we can link that at compile time ? :-].

	I guess - if this would only ever be used for bits of code that are
going to be in the main mergelibs domain & thus could be directly linked
and evaporated away at compile time: and assuming that we subsequently
avoid those being registered in services.rdb I guess it's no issue:
beyond lots more typing, and scope for typos/errors :-)

	I suspect though that mergelibs will not encompass all components
though, and that thus we'll end up with lists of this duplication around
the place still (?).

	ATB,

		Michael.

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