Efficient UNO component linkage & GC ...

[Michael Meeks]

On Mon, 2014-01-06 at 16:45 +0100, Stephan Bergmann wrote:
> > 	? :-) 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.

	Is there a practical example of this anywhere ? and/or can we not
default to doing the efficient thing and have the casual bloat version
as a fallback ? ;-)

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

	Are the impl. names not exposed to the scripter / programmer ?

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

	Sure; so - if we have that data around in a structure, it'd be great
not to duplicate it in the XML and also in the C++ :-) it'd be nice to
have the strings in one DSO only - if we even need them at all :-) [ are
they just a mapping detail ? ].

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

	Sure - my concern is that before we push this across the code-base,
it'd be nice to rid ourselves of the factory functions and come up with
something that is efficient, minimal, as simple as possible, and -then-
push it over a thousand+ call-sites / XML entries etc. Rather than for
each small change having to manually re-touch all that lot.

	ATB,

		Michael.

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