extraordinary stoc/ thrash ...

[Stephan Bergmann]

[putting libreoffice@ back on cc]

On 04/04/2012 11:05 PM, Tomas Hlavaty wrote:
> Hi Stephan,
>
>> First of all, remember that we have two different scenarios where we
>> want to replace the old binary rdb format with something else, once
>> for type information and once for service information.
>
> I see.
>
>> (The decision to replace the old binary rdb format with an XML format
>> for service information was mostly born out of convenience.  In
>> itself, it does not look especially problematic, performance-wise.
>> While this is certainly open for debate and inspection, I just don't
>> think it is relevant for the problem at hand.)
>
> But don't we have to maintain this information twice then?  Once in the
> IDL files and then as XML?

Not in the case of services rdbs.  The information stored there is a 
mapping between (a) service and singleton names (as documented in 
UNOIDL), (b) the implementation names of entities implementing those 
singletons and services, and (c) the software artefacts that contain 
those implementations (dynamic libraries, jars, etc.).

For types rdbs, on the other hand, the information is indeed currently 
duplicated (triplicated even, given the additional representation as 
Java class files).  Improvement here is surely desirable.

>>>> I think the problem is not the XML parsing, but the nested XRegistry
>>>> list.
>>>
>>> Does "nested XRegistry list" mean the registry structure mirroring the
>>> symbol hierarchy of uno packages/classes?  Why is that a problem?
>>
>> No.  The nesting (or linear list, rather) represents the various files
>> from which service information is obtained.  (And one of the most
>> important ones, LO's program/services/services.rdb tends to only come
>> near the very end of that list.)
>
>  From this description it seems that the problem is not nesting but
> rather _lack_ of nesting (or efficient look up) in the way things are
> looked up in the internal representation of rdb files.  Is my
> understanding correct?

Yes, however you want to put it, the assumption is that retrieving the 
relevant information from the data set is sub-optimal.  My tinkering 
with a radically simplified component context/service manager is going 
along quite well, btw.  I hope I have enlightening numbers soon.

Stephan

>>>> 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.
>>
>> The question of on-disk data format (for both type and service
>> information) would be rather orthogonal to this work.
>
> Great.
>
> Thank you,
>
> Tomas