Encourage usage of XPath in rules.xml

[jensens]

I had now some performance consulting jobs where I had to speed up diazo. Primary problem was usage of many global queries introduced by css selectors. In bobtemplates.plone's rules.xml we should encourage usage of xpath with absolute selectors where possible.

[jensens]

a major speed-up is to change current

<rules css:if-content="#visual-portal-wrapper">

to (Plone 4):

<rules if-content="/html/body/div[@id='visual-portal-wrapper']">

or Plone 5:

<rules if-content="/html/body[@id='visual-portal-wrapper']">

because this rule is expanded multiple time in the XSL and do a expensive global search.

[davilima6]

From previous threads, I've been led to understand that there wasn't too much performance difference from using CSS selectors instead of XPath. What seemed much a bigger difference is providing full (more specific) selectors, so div#visual-portal-wrapper would be way faster than #visual-portal-wrapper only. Not sure about html > body > div#visual-portal-wrapper, but I don't think that helps; only specifying the tag element does enough.

I don't think we should make XPath a best practice but instead fix CSS selectors's performance because that would hurt a lot the theming story (you don't need to know Plone to theme it because Diazo).

[davilima6]

Actually wrapping all your rules in #visual-portal-wrapper is recommended to be avoided. It's better to use a <notheme> rule, as in Barceloneta. That way the condition doesn't get repeated over and over in your XSLT.

Finally I'm not completely sure what this rule is for. In early XDV days it served to avoid theming the ZMI but IIRC that's no longer needed after a special marker was added to ZMI requests.

[MrTango]

I would like to see some documented research here, before we decide how we want to do it per default. Last time we tried we could really measure the differences. I'm ok with having importent wrapper rules in XPath if necessary, but not all rules in XPath as it's way more verbose and error-prone.

[jensens]

Well, XPath is way more explicit. And my intern (never coded before) learned basic XPath in 4 hours.

The speed-up is very significant (exponential) with the page length. So, with simple short page one may not see any significant speedup, but long-scrolling pages do.

The problem is, the currently usage of cssselect is not very clever. It produces very complex global searching XPath constructs, which are expensive to compute. And Diazo then uses this output and repeats them all over the place.

To get a feeling of what happens: just take the Diazo-compiler with some more complex theme and compile the XSS-file. Open it in an editor and you'll see several of complex repeated XPath.

We may need an optimization in Diazo which collects similar queries and stores the result in a variable. But that is out of scope here. And as long we have this problem I see no better solution than using more optimized XPath directly.