Re: Slow XSLT

On 02/03/2008, Cleyton Jordan <cleytonjordan@xxxxxxxxxxx> wrote:
>  One thing I will have to figure out is a way to
>  measure the speed improvement. I do not want to only
>  look at the watch and count the seconds.
>
>  I might use Javascript with the time function and
>  alert how long each approach takes (start time - end
>  time). Do you have any suggestions on how I could
>  measure that in an easier way?
As XSLT does not allow you to measure time intervals (side-effects),
it would be best to use Javascript for that.

>  Also, I did not quite understand your the simpler
>  approach suggestion. Could you please elaborate a bit
>  more on that?
>
>  > Another (simpler) approach would be to limit the
>  > maximum number of
>  > dimensions for the table so you can use match
>  > patterns like
>  > match="ColGrp"
>  > match="ColGrp/ColGrp"
>  > match="ColGrp/ColGrp/ColGrp"
>  > match="ColGrp/ColGrp/ColGrp/ColGrp"
>  > match="ColGrp[Col]"
>  > match="Col"
Templates with these match patterns would process ColGrp elements with
the same "depth" only and you would know in advance which one it is.
You also may want to make the priority of those templates explicit by
using priority="nn" where nn=10, 11, 12, 13 and 14 (from top to
bottom) for 5 levels of ColGrp elements.
   match="ColGrp" priority="10"
   match="ColGrp/ColGrp" priority="11"
   match="ColGrp/ColGrp/ColGrp" priority="12"
   match="ColGrp/ColGrp/ColGrp/ColGrp" priority="13"
   match="ColGrp[Col]" priority="14"
If you get a ColGrp element to be processed (because of the intrinsic
selection process) then a match with the templates is attempted in
priority order. The second match pattern for example specifies
"ColGrp/ColGrp" which means it will take any ColGrp elements which
have an other ColGrp element as its parent. Because of the priority
rules it matches only the depth=1 level.

Hope this helps,

Manfred
If the table happens to have less than maximum levels this would do no
harm (performance-wise).