extraordinary stoc/ thrash ...
sbergman at redhat.com
Tue Apr 3 01:41:01 PDT 2012
On 04/02/2012 11:06 PM, Michael Meeks wrote:
> Digging through the string logs, trying to make sense of the extremely
> intense thrash around this SINGLETON/ stuff, I was curious to get rather
> deep stacks, cf. appended trace.
> AFAICS the purpose of this code is mostly to turn a pretty simple,
> pretty flat XML structure, into a simple list of singletons that we can
> then whack into a hash table somewhere else.
> Is all this heavy-lifting really necessary for that ? it seems just a
> little intense :-)
> I'm also curious if the performance issue here (this code features
> reasonably high on a startup profile IIRC) might be related to the
> multiple '.rdb' file code (?).
Yes, this is indeed a bit of a tragedy. The relevant UNO types and
services bootstrapping code is very old, and concepts are tightly knit
together there, and whenever you want to change something you risk
backwards incompatibility. The code causes mental pain, and whenever
you need to touch it you want to run away screaming. One typically ends
up doing minimally invasive changes. That way, you have a chance of
surviving the process. But you also pile up guilt.
At the heart of the matter there is the old binary "store" file
structure and the XRegistry interface on top of it. At runtime, both
all the UNO type information (scattered across a number of binary rdb
files) and all the UNO service information (scattered across a number of
rdb files that used to be binary but have been mostly changed to XML
now) are represented by a single XRegistry instance each.
The way the respective information is represented in the XRegistry
interface simply corresponds to the way the information is stored in the
binary rdb files. Those files are designed for storage of
hierarchically nested small blobs of information. Hence, for example
information about a UNO interface type com.sun.star.foo.XBar is stored
in a nested "folder" with path com - sun - star - foo - XBar, containing
little blobs of information about the type's ancestors, its methods,
etc. Similarly for information about instantiable services like
As there are typically multiple rdb files containing types resp.
services (URE specific, LO specific, from extensions, ...), but they
need to be represented by a single XRegistry instance, so "nested
registries" were invented. They effectively form a linear list of
chaining XRegistry instances together. Whenever a path needs to be
looked up in the top-level registry, it effectively searches through the
linear list of nested registries. All with the cumbersome UNO XRegistry
interface between the individual parts. Horror.
When I introduced XML service rdbs, I sort of chickened out (see above
for rationale) and put them behind an XRegistry facade, so that they
would seamlessly integrate with the existing mess. I postponed
systematic clean-up to the pie-in-the-sky days of LO 4 (or, "once we'll
become incompatible with OOo," as the phrase used to be back then).
So, while the situation is catastrophic, I do not think it has become
significantly more catastrophic in recent times. It can well have
gradually degraded, though. For example, each types or services rdb
that is added into the game makes the corresponding linear list of
nested registries longer. And I wouldn't be surprised if some of the
XRegistry-nesting nonsense causes overhead that is effectively quadratic
in the length of that linear list...
This Gordian knot is not easily slain, however. As I said, things are
tightly knit. Of the various bootstrapping methods offered by
cppuhelper, some even offer not to distinguish among types and services
rdbs -- you could lump everything together, and the code would sort out
the mess, through enquiries of the uniform XRegistry interface.
I guess I'll have to have a look at that mess once more (and hopefully
for the last time). -- We need to get started with our journey to LO 4
dreamland anyway, I'd say.
More information about the LibreOffice