Functions that return nodes and output streaming

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Functions that return nodes and output streaming

max toro q
I have a question about XSLT and Saxon's implementation.

I suspect that templates that return nodes do not need to create an
in-memory temporary tree because they can write to the same "output"
as the caller, which is usually a final result tree (unless called
from a variable).

But what about functions? Do functions always create an in-memory
temporary tree? Or is there some trick that understands, for example
`<xsl:sequence select="my:create-node()"/>` and decide it's OK to
write directly to that sequence constructor's "output", instead of
creating a temporary tree and then copying that.
--
Max Toro

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Functions that return nodes and output streaming

Michael Kay
I’m afraid that’s a simple question with a very complicated answer.

Firstly, if functions are simple enough then they get inlined. In that case anything might happen, but basically they are executed exactly as if you replaced the function call with the body of the function, substituting any parameters as needed.

Functions can operate in either “push” or “pull” mode. In push mode, instructions “write to the result tree”, they use the processing model rather the way that XSLT 1.0 described it, except that the result “tree” is actually a stream of SAX-like events. If you write this as the body of a function:

<a>
  <xsl:value-of select=“x”/>
</a>

then the function first pushes a startElement event, then a text node, then an endElement event.

In pull mode, an in memory tree is constructed containing the element node, and the function returns (a reference to) this node. That’s more like the processing model is described in the 2.0 specs.

(Complicating things further there is also a “pull events” mode where the function returns an event iterator which on demand delivers a sequence comprising a startElement event, a text node, and an endElement event. But this isn’t activated by default; it’s there primarily for one particular company that integrates Saxon into its products and invokes it in this way).

The decision whether to invoke a function in pull or push mode depends on a number of factors, and it’s made slightly differently depending on whether bytecode generation is in use. Essentially the decision is made by the caller, not by the function itself. If the caller is currently running in push mode, it invokes the function in push mode, and vice versa. The caller will be running in push mode if the function call occurs in a context like

<a>
  <xsl:sequence select=“f()”/>
</a>

and in pull mode if it occurs in a context like

<a>
  <xsl:sequence select=“f() + 2”/>
</a>

That’s because element constructors like to work in push mode, while arithmetic expressions like to work in pull mode.

We do know that getting the choice of pull mode or push mode right can make a big difference to overall performance (e.g. a factor of three or four).

Templates, for various reasons, are always called in push mode.

Hope that helps!

Michael Kay
Saxonica


> On 16 Sep 2015, at 02:55, Max Toro <[hidden email]> wrote:
>
> I have a question about XSLT and Saxon's implementation.
>
> I suspect that templates that return nodes do not need to create an
> in-memory temporary tree because they can write to the same "output"
> as the caller, which is usually a final result tree (unless called
> from a variable).
>
> But what about functions? Do functions always create an in-memory
> temporary tree? Or is there some trick that understands, for example
> `<xsl:sequence select="my:create-node()"/>` and decide it's OK to
> write directly to that sequence constructor's "output", instead of
> creating a temporary tree and then copying that.
> --
> Max Toro
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Functions that return nodes and output streaming

max toro q
Thanks Michael, it makes perfect sense.
--
Max Toro


On Wed, Sep 16, 2015 at 4:37 AM, Michael Kay <[hidden email]> wrote:

> I’m afraid that’s a simple question with a very complicated answer.
>
> Firstly, if functions are simple enough then they get inlined. In that case anything might happen, but basically they are executed exactly as if you replaced the function call with the body of the function, substituting any parameters as needed.
>
> Functions can operate in either “push” or “pull” mode. In push mode, instructions “write to the result tree”, they use the processing model rather the way that XSLT 1.0 described it, except that the result “tree” is actually a stream of SAX-like events. If you write this as the body of a function:
>
> <a>
>   <xsl:value-of select=“x”/>
> </a>
>
> then the function first pushes a startElement event, then a text node, then an endElement event.
>
> In pull mode, an in memory tree is constructed containing the element node, and the function returns (a reference to) this node. That’s more like the processing model is described in the 2.0 specs.
>
> (Complicating things further there is also a “pull events” mode where the function returns an event iterator which on demand delivers a sequence comprising a startElement event, a text node, and an endElement event. But this isn’t activated by default; it’s there primarily for one particular company that integrates Saxon into its products and invokes it in this way).
>
> The decision whether to invoke a function in pull or push mode depends on a number of factors, and it’s made slightly differently depending on whether bytecode generation is in use. Essentially the decision is made by the caller, not by the function itself. If the caller is currently running in push mode, it invokes the function in push mode, and vice versa. The caller will be running in push mode if the function call occurs in a context like
>
> <a>
>   <xsl:sequence select=“f()”/>
> </a>
>
> and in pull mode if it occurs in a context like
>
> <a>
>   <xsl:sequence select=“f() + 2”/>
> </a>
>
> That’s because element constructors like to work in push mode, while arithmetic expressions like to work in pull mode.
>
> We do know that getting the choice of pull mode or push mode right can make a big difference to overall performance (e.g. a factor of three or four).
>
> Templates, for various reasons, are always called in push mode.
>
> Hope that helps!
>
> Michael Kay
> Saxonica
>
>
>> On 16 Sep 2015, at 02:55, Max Toro <[hidden email]> wrote:
>>
>> I have a question about XSLT and Saxon's implementation.
>>
>> I suspect that templates that return nodes do not need to create an
>> in-memory temporary tree because they can write to the same "output"
>> as the caller, which is usually a final result tree (unless called
>> from a variable).
>>
>> But what about functions? Do functions always create an in-memory
>> temporary tree? Or is there some trick that understands, for example
>> `<xsl:sequence select="my:create-node()"/>` and decide it's OK to
>> write directly to that sequence constructor's "output", instead of
>> creating a temporary tree and then copying that.
>> --
>> Max Toro
>>
>> ------------------------------------------------------------------------------
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help