[Setup] huge performance issues using Diazo

Laurence Rowe l at lrowe.co.uk
Sun Apr 1 13:07:25 UTC 2012


Laurence Rowe wrote
> 
> 
> hvelarde wrote
>> 
>> just to let you know how we reduced the process time from 25 to 2.5 
>> seconds: we changed most conditional rules from CSS3 to XPath selectors.
>> 
>> here is an example:
>> 
>> -    <rules css:if-content=".template-section-view,
>> -                           .template-opinion-view,
>> -                           .template-opinion-interview-view,
>> -                           .template-opinion-context-view">
>> +    <rules if-content="//*[contains(@class, 'template-section-view')] or
>> +                       //*[contains(@class, 'template-opinion-view')] or
>> +                       //*[contains(@class, 
>> 'template-opinion-interview-view')] or
>> +                       //*[contains(@class, 
>> 'template-opinion-context-view')]">
>> 
>> Diazo documentation states that: "CSS selectors are replaced by the 
>> equivalent XPath selector during the pre-processing step of the 
>> compiler. Thus, they have no performance impact."
>> 
>> this seems to be false according to what we have found.
>> 
> 
> No, your selectors are not equivalent. The xpath "//*[contains(@class,
> 'template-section-view')]" matches any element with
> 'template-section-view' in the class. That could be  or equally 
> 
> The reason it is so slow is that every single rule you have is testing
> that there is any element in the page with that class. Those are body
> classes and you should be restrict them to the body element where they
> appear, i.e.:
> 
> 
> 
> This should reduce your XSLT execution time by two orders of magnitude.
> 

Further to this, there's a bug in our fork of experiemental.cssselect (fixed
in newer versions of lxml after our fork) where spaces in CSS are not parsed
correctly causing the comma+space separated selectors to be compiled to
exceptionally slow XPaths. This should account for the ~30s timings you've
seen. I'll make another release in the next few days which will also
incorporate some of the simpler class selector optimizations.

There are a couple of options to fix the ~3s timings though these are rather
more involved and I can't promise when I'll get to those yet. I'd like to
make it difficult to write a theme that takes more than a few hundred ms to
execute on reasonably long pages.

It would be really helpful if people could publish their themes (rules.xml,
theme html and example content html, no need for CSS/images) in a way that
would let me incorporate them into a benchmark, particularly if they are
very slow.

Laurence

--
View this message in context: http://plone.293351.n2.nabble.com/huge-performance-issues-using-Diazo-tp7372056p7426744.html
Sent from the Installation, Setup, Upgrades mailing list archive at Nabble.com.


More information about the Setup mailing list