I want to generate an xpath to a document in an XSLT extension to
hopefully allow a macro to be slightly more performant than by just
returning a nodeId (i.e. if I return a nodeId of 1001, running a
/descendant [@id = 1001] xpath can't b a good thing). I was thinking of
using the path property of a given document (-1, 1001,1002,1003) to
generate an XPATH such as:
/* [isDoc and @id=1001]/* [isDoc and @id=1002]/* [isDoc and @id=1003]
Would this be the way to go, or would there be a way that would be quicker in both :
- The generation of the xpath based on the given known, umbraco attributes of all nodes
Curious to your concerns over performance of the XPath like "/descendant-or-self::*[@id = 1003]"?
Have you noticed any performance issues?
While it does make sense that providing the "path" to help navigate the XPath query would be mroe performant, I'm not sure how much of a gain you'll get.
An alternative (if you just had the @id) would be to use "umbraco.library:GetXmlNodeById(1003)", as that will retreive the XML node directly from the DOM.
Never done any performance benchmarks on these approaches, always found them all to be fast.
Thats good to know. We've not benchmarked it, but we just assumed it might be slow (kind of like doing a "like" in SQL), conversly we thought the more defined / absolute / direct an XPath could be the better?
You have to benchmark it. You don't know what sort of optimisations the parser is doing behind the scenes.
You could also look at defining a key which would preindex everything, although that is only going to be useful if you are looking at a lot of queries for the same criteria fields in one macro run; no point doing it for a single query. I've never used keys in Umbraco as not had a large enough site to require it.
Re: umbraco.library:GetXmlNodeById(1003); it certainly appears at first glance like that should be the way to go, but if all it is doing is a SelectSingleNode with a similar path to your own, then I doubt the performance would change, as it'd basically be doing whatever the parser does to run your transform.
It could of course be using preindexed nodes, as Umbraco knows that @id is special, so preindexing them for fast retrieval would be sensible. You could look at the Umbraco source, but really, benchmarking is the way to go!
Just out of interest, how many nodes in your tree?
Generate an XPATH to a node from a given nodeId
I want to generate an xpath to a document in an XSLT extension to hopefully allow a macro to be slightly more performant than by just returning a nodeId (i.e. if I return a nodeId of 1001, running a /descendant [@id = 1001] xpath can't b a good thing). I was thinking of using the path property of a given document (-1, 1001,1002,1003) to generate an XPATH such as:
/* [isDoc and @id=1001]/* [isDoc and @id=1002]/* [isDoc and @id=1003]
Would this be the way to go, or would there be a way that would be quicker in both :
- The generation of the xpath based on the given known, umbraco attributes of all nodes
- The execution of the generated xpath
Regards
Janusz
Hi Janusz,
Curious to your concerns over performance of the XPath like "/descendant-or-self::*[@id = 1003]"?
Have you noticed any performance issues?
While it does make sense that providing the "path" to help navigate the XPath query would be mroe performant, I'm not sure how much of a gain you'll get.
An alternative (if you just had the @id) would be to use "umbraco.library:GetXmlNodeById(1003)", as that will retreive the XML node directly from the DOM.
Never done any performance benchmarks on these approaches, always found them all to be fast.
Cheers, Lee.
Hi Lee
Thats good to know. We've not benchmarked it, but we just assumed it might be slow (kind of like doing a "like" in SQL), conversly we thought the more defined / absolute / direct an XPath could be the better?
You have to benchmark it. You don't know what sort of optimisations the parser is doing behind the scenes.
You could also look at defining a key which would preindex everything, although that is only going to be useful if you are looking at a lot of queries for the same criteria fields in one macro run; no point doing it for a single query. I've never used keys in Umbraco as not had a large enough site to require it.
Re: umbraco.library:GetXmlNodeById(1003); it certainly appears at first glance like that should be the way to go, but if all it is doing is a SelectSingleNode with a similar path to your own, then I doubt the performance would change, as it'd basically be doing whatever the parser does to run your transform.
It could of course be using preindexed nodes, as Umbraco knows that @id is special, so preindexing them for fast retrieval would be sensible. You could look at the Umbraco source, but really, benchmarking is the way to go!
Just out of interest, how many nodes in your tree?
Not sure yet. Its a multi-site implemenation for 120 websites. Probably looking at about max 100 nodes per site I would say. So around 12,000?
Hi Janusz,
I'd definitely do some benchmarking if you're at all curious as to which approach is best in your particular setup.
I honestly think that the battle will be between GetXmlNodeById() and a "clean" XSLT key - which I think will be pretty fast.
Please post back here if/when you have some results to share.
/Chriztian
is working on a reply...