Re: [xsl] Complex recursion in XSLT 1.0

Subject: Re: [xsl] Complex recursion in XSLT 1.0
From: "Manfred Staudinger" <manfred.staudinger@xxxxxxxxx>
Date: Thu, 21 Feb 2008 17:51:23 +0100
On 21/02/2008, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> One very minor observation: I think (though I would need to verify by
>  testing) that in Saxon this might perform better if you added elements at
>  the end rather than the start. In particular, this might allow the "new"
>  stack to share underlying space with the "old" stack in many cases, and to
>  avoid physical copying.

Very interesting indeed. Does this mean also that a LILO (last-in
becomes last-out) stack is to be preferred against LIFO (last-in
becomes first-out) ...

On 21/02/2008, Florent Georges <lists@xxxxxxxxxxxx> wrote:
>   And if I remember well, sequences in Saxon are represented
>  by iterators (so one knows the front directly, not the end).

... because it seems rather difficult to make LIFO symmetric in terms
of performance to the LILO stack at the level of XSLT.

Manfred

On 21/02/2008, Florent Georges <lists@xxxxxxxxxxxx> wrote:
> Michael Kay wrote:
>
>   Hi
>
>
>  > One very minor observation: I think (though I would need
>  > to verify by testing) that in Saxon this might perform
>  > better if you added elements at the end rather than the
>  > start. In particular, this might allow the "new" stack to
>  > share underlying space with the "old" stack in many cases,
>  > and to avoid physical copying.
>
>
>   Very interesting.  I put the new element at the front,
>  actually because I thought it would avoid some copies...
>  I don't explicitely know why, I guess that comes from the
>  Lisp's cell model?
>
>   And if I remember well, sequences in Saxon are represented
>  by iterators (so one knows the front directly, not the end).
>  What should be the real Java object underlying the sequence
>  at the very end (the object that would require copy)?
>
>
>  > (I seem to be unusual in that I think of the top of the
>  > stack as being at the high-address end. Comes from years
>  > of exposure to a hardware architecture that worked that
>  > way.)
>
>
>   Doesn't seem unusual if you only think of a stack as a
>  "thing" you can apply pop, top and push to, with a few
>  relations between the state of the "thing" and those
>  functions :-)
>
>
>   Regards,
>
>  --drkm

Current Thread