Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.