[Setup] huge performance issues using Diazo

Laurence Rowe l at lrowe.co.uk
Thu Apr 5 00:01:29 UTC 2012

Laurence Rowe wrote
> 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.

Actually the whitespace bugfix in lxml I was referring to was something
else. I've fixed this whitespace issue (and made a pull request to lxml) and
released experimental.cssselect 0.3. Update your version pins.

With this change I benchmarked the ploneorg theme with a
css:if-content=".section-foo, .section-documentation" on the root rules
element against a 20k and 565K documentation page. With the 20K document,
execution time dropped to ~25ms from ~95ms. With the 565K document, the
execution time dropped to ~1200ms and did not complete in several minutes
with the previous version.

Changing the condition to css:if-content="body.section-foo,
body.section-documentation" dropped execution time for the 20K document to
~7ms and for the 563K document to ~230ms using either the new or old

Without the condition, the ploneorg theme executed in ~5ms for the 20K
document and ~140ms for the 563K document. Optimizing the theme conditions
to use an xsl:key indexes on @id dropped execution time to ~2ms and ~60ms


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

More information about the Setup mailing list