I'm posting this on behalf of Brendan Rice - Matt Bliss
I have a performance issue in an XSLT file that I am finding it
tricky to track down.
The XSLT is based off Doug's excellent XSLTsearch package XSLT
file and the performance issues seem to creep in before the "After
performing transformation" trace log (see below it takes 2.4 seconds).
There are a few modifications to the script so it is likely one
of them causing it.
Has anyone got any tips or pointers of how best to go about
putting log messages in the script to get timings from the trace to help
pinpoint where the time is being sucked up?
umbracoXsltExtension
Extension added:
urn:PS.XSLTsearch, XSLTsearch
1.135309
0.000013
umbracoMacro
After adding extensions
1.135318
0.000008
umbracoMacro
Before performing
transformation
1.135351
0.000033
SearchHelper
1. Pre Query
1.136304
0.000954
SearchHelper
2. jobsRegion
1.136346
0.000042
SearchHelper
3. jobSector
1.136358
0.000012
SearchHelper
4. jobDegree
1.136375
0.000017
SearchHelper
5. jobType
1.136385
0.000010
SearchHelper
6. sortXpath
1.136397
0.000012
SearchHelper
Post Query 1
1.544537
0.408140
SearchHelper
Post Query 1 -
Query//descendant-or-self::* [@isDoc and @id='28188' ]/descendant-or-self::*
[@isDoc and (name() = 'MyPage') and isClosed !='1' and (number(variable1)
>= number('0') and number(variable1) < number('9999999'))]
XSLT Performance Issue
I have a performance issue in an XSLT file that I am finding it tricky to track down.
The XSLT is based off Doug's excellent XSLTsearch package XSLT file and the performance issues seem to creep in before the "After performing transformation" trace log (see below it takes 2.4 seconds).
There are a few modifications to the script so it is likely one of them causing it.
Has anyone got any tips or pointers of how best to go about putting log messages in the script to get timings from the trace to help pinpoint where the time is being sucked up?
umbracoXsltExtension
Extension added: urn:PS.XSLTsearch, XSLTsearch
1.135309
0.000013
umbracoMacro
After adding extensions
1.135318
0.000008
umbracoMacro
Before performing transformation
1.135351
0.000033
SearchHelper
1. Pre Query
1.136304
0.000954
SearchHelper
2. jobsRegion
1.136346
0.000042
SearchHelper
3. jobSector
1.136358
0.000012
SearchHelper
4. jobDegree
1.136375
0.000017
SearchHelper
5. jobType
1.136385
0.000010
SearchHelper
6. sortXpath
1.136397
0.000012
SearchHelper
Post Query 1
1.544537
0.408140
SearchHelper
Post Query 1 - Query//descendant-or-self::* [@isDoc and @id='28188' ]/descendant-or-self::* [@isDoc and (name() = 'MyPage') and isClosed !='1' and (number(variable1) >= number('0') and number(variable1) < number('9999999'))]
1.544589
0.000052
SearchHelper
Post Query 1 - Count - 257
1.786802
0.242213
umbracoMacro
After performing transformation
4.218481
2.431680
Thanks for posting this for me Matt, really appreciate the help
Hi Brendan & Matt,
It's very likely due to some XPath queries going through way more nodes than necessary. Could you post a link to the XSLT (Gist/Pastebin) maybe?
You might also have a look at using keys to solve the problem: http://our.umbraco.org/forum/developers/xslt/35132-Slow-node-selection-with-large-amount-of-nodes
/Chriztian
Hi Chriztian,
thanks for replying, XSLT is in the gist URL below:
https://gist.github.com/4513384
there is a call to an extension on 113 but I pretty sure that isn't what is slowing down the XSLT as that is what 1-6 in the trace is recording.
Any help would be great, thanks again for taking the time.
B
is working on a reply...