extraordinary stoc/ thrash ...

Stephan Bergmann sbergman at redhat.com
Thu Apr 5 05:23:13 PDT 2012

On 04/03/2012 02:27 PM, Stephan Bergmann wrote:
> I have a vague idea of placing yet another cppuhelper bootstrap
> mechanism next to the existing ones, which will internally use
> completely different (read: cheap) mechanisms to set up a component
> context and associated service manager. That way, I would avoid most of
> the hassle of having to whack improvements into a rotten framework.
> I'll toy around with that in the next days/weeks. Hang on...

The attached defaultbootstrap.patch is work in progress along that way. 
  It adds a new cppu::defaultBootstrap() to replace 
cppu::defaultBootstrap_initialComponentContext(), and hooks that up in 

Internally, defaultBootstrap tries to be slim and streamlined and avoid 
to reach out into the overly generic world of UNO infrastructure 
services as much as possible.  It is still completely unfinished, though:

* It can only read new style, XML service rdbs.  This should not be a 
big problem, as all the service rdbs contained in a LO installation are 
in that format now, and extensions never bring along their own service 
rdbs.  However, extension management still maintains 
files in the old format.  So the code that writes those must be 
converted to use the XML format, and upgrading LO must make sure that 
the data in existing user installations is converted.  For now, I work 
around that problem by removing all extensions from the LO 
installation's share/extensions/ and starting with a fresh user 

* The ServiceManager implementation shortcuts loading of dynamic 
libraries, not going via an instance of the 
com.sun.star.loader.SharedLibrary loader.  For one, this matches the 
spirit of not reaching out into the overly generic UNO infrastructure 
where possible.  For another, this is necessary however to pass the new 
prefix attribute to the loader, as XImplementationLoader.activate passed 
that information indirectly via the XRegistryKey parameter -- which 
becomes an obsolete parameter now that we are no longer registry-based. 
  (This is an example of the tight knitting here that causes so much 
pain when you want to change something.)  Other loaders (for Java, 
Python, etc. components) are not yet hooked up.

* Much of the ServiceManager's additional UNO interface stuff is not yet 
implemented.  Especially for live deployment of extensions, we'll need 
support of the XSet interface.

* Type information is still obtained the old way, via those dreaded 
nested registries.

As for hard performance data, I only tested with a recent master 
--enable-dbgutil build yet.

$ time .../soffice --terminate_after_init

went from 13.622s to 10.768s for the first (kind of "cold," but far from 
meaningful, esp. as I ran the old before the new, with no cache-cleaning 
in between) run, but subsequent runs always stay around 0.85s in both 
cases (all times wall clock).

$ time .../soffice # hit ^C when start center is up

did not show significant differences (but of course also suffers from 
the necessary manual activity).  Using

> diff --git a/sal/rtl/source/strimp.hxx b/sal/rtl/source/strimp.hxx
> index 82f7f41..1c1f57a 100644
> --- a/sal/rtl/source/strimp.hxx
> +++ b/sal/rtl/source/strimp.hxx
> @@ -55,7 +55,7 @@ sal_Int16 rtl_ImplGetDigit( sal_Unicode ch, sal_Int16 nRadix );
>  sal_Bool rtl_ImplIsWhitespace( sal_Unicode c );
>  // string lifetime instrumentation / diagnostics
> -#if 0
> +#if 1
>  #  include <rtl/ustring.hxx>
>  #  define RTL_LOG_STRING_NEW(s)                                              \
>        do {

to enable Michael's string instantiation counts and then

$ .../soffice 2>&1 | grep '^+' | wc -l # hit ^C when start center is up

shows a decrease from 166452 to 127501, though, so I'm likely not on a 
completely wrong track.

Happy Easter,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defaultbootstrap.patch
Type: text/x-patch
Size: 55381 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120405/49a1cff4/attachment-0001.bin>

More information about the LibreOffice mailing list