Re: extraordinary stoc/ thrash ...

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 
com.sun.star.baz.Boz.
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.
Stephan