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 experimental.cssselect. 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 respectively. Laurence -- 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. _______________________________________________ Setup mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-setup
