Andy Black wrote:
> On 11/3/2008 9:20 AM, Hussein Shafie wrote:
>> Andy Black wrote:
>>> We've just learned that a large (540KB) XML file for one of our
>>> custom configurations loads very slowly in version 4.1.0. In version
>>> 3.8.1 it takes about 12 seconds, but in 4.1.0 it takes about 5
>>> minutes and 20 seconds. We are using the Personal Edition in both
>>> cases.
>>>
>>> Is this a known problem? (I tried looking for something on this in
>>> the archives for this list, but did not find anything.)
>>>
>>> 12 seconds to load is fine, but over 5 minutes is a bit daunting.
>>> Are there plans to address this?
>> I'm almost sure you are comparing XXE v3.8.1 with custom configuration
>> A to XXE v4.1 with custom configuration A' (which is enhanced custom
>> configuration A).
>
> Ah, yes. You are correct.
>
>> Your CSS style sheet contains many rules like this one:
>> ---
>> iword item
>> {
>> display:block;
>> color: concatenate(xpath("id(@lang)/@color"));
>> font-family: concatenate("'",xpath("id(@lang)/@font-family"),"'");
>> font-size: concatenate(xpath("id(@lang)/@font-size"));
>> font-style: concatenate(xpath("id(@lang)/@font-style"));
>> font-weight: concatenate(xpath("id(@lang)/@font-weight"));
>> }
>> ---
>>
>> The performance problem comes from the "id()" XPath function. There is
>> simply no way to make this kind of rule fast in the context on an XML
>> editor (while this is not a problem for a browser or for an XSLT
>> processor).
>
> Sigh.
>
>> This has always been the case, even in XXE v3. By the way, this part
>> of the code has not changed at all between v3 and v4.
>>
>> I did a very simple optimization which divided by 5 the load time of
>> your document. Before the optimization it took 11mn30s (on my old,
>> slow, desktop) to load your document. After this optimization, it took
>> 2mn40s, which is still totally unacceptable.
>
> Is this optimization you did available to us?
This optimization of our CSS engine, being useful in the general case
whenever xpath() is used, will be part of next release.
> That is, is there something I can do in the configuration files?
>
No. It is an optimization of our CSS engine, that is, Java[tm] code.
>> I've also implemented another strategy to handle id() in the context
>> of CSS rules, and found it to be slower than current strategy (once
>> optimized). So I gave up this alternative strategy.
>>
>> I'm really sorry but there is nothing more I can do for your problem.
>> I can just recommend to keep the number of CSS rules making use of
>> id() to the bare minimum.
>
> OK, I hear you, although I am disappointed to hear it. Most, if not
> all, of these usages of id() are an attempt to render element X using
> the font properties of element Y, where an attribute on X is an IDREF to
> element Y. Is there some other way to do this without using id()?
>
I would replace:
id(@foo)/@wiz
by something like:
//b...@id = current()/@foo]/@wiz
That is, get rid of id() by replacing it by a specific XPath.
(Just saying that off the top of my head. Didn't test it. However if it
works, you should have less performance problems.)
