Dimitre,
I don't think the document is being discarded. I assume the processor is seeing that it is still needed and retaining it.

I changed my template to load the document into a temporary tree at the very beginning, and that did not change the runtime by more than a few seconds, so I don't think it has anything to do with the document being re-read.

I'm wondering if the key is having to be re-created every time (in the push processing version) because the document node being passed to the child template is being considered a fresh document each time.

I'm working on a specific case I can send out as an example.

-David

On Sat, Jun 23, 2012 at 5:19 PM, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
David, it simply isn't logical to discard the documen if you still need it.

This is the cause f the problem and it has nothing to do with "push processing".


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.


On Sat, Jun 23, 2012 at 7:08 AM, David Rudel <fwqhgads@gmail.com> wrote:
> Thanks, Michael,
>
> I don't actually use predicates in the template matching rules. I was just
> doing that for sake of illustration.
>
> However, I do use "saxon:discard-document" a lot, and I suspect that might
> be the problem. Often I use it in a way that is probably %100 okay, like as
> the source document for a very large "For-each-group" command that may have
> lots of complex stuff nested inside:
>
> <xsl:for-each select="//employee">
> <xsl:for-each-group select="saxon:discard-document(document(@file))"
> group-by"date">
> ....
> ....
> ....
> </xsl:for-each-group>
> </xsl:for-each>
>
> But in this particular program I'm using it to hold a document that I later
> search over and over again using a key:
> <xsl:variable name="employee_info"
> select="saxon:discard-document(document(@file))"/>
>
> and then later I'll use key('datakey',@id,$employee_info) or whatever.
>
> Would it be better to use the file to create a temporary document instead?
> This is, by the way, the variable I'm passing along to the apply-template
> function. Does the above help explain why I am taking a hit using
> push-processing?
>
> -David
>
>
>
>
>
> On Sat, Jun 23, 2012 at 3:46 PM, Michael Kay <mike@saxonica.com> wrote:
>>
>> Difficult to tell without seeing your full code:
>>
>> (a) if you have a very large number of templates of the form
>>
>>
>> <xsl:template match="task[@type='dishes']>
>>
>> i.e. all matching the same element name, but with different predicates,
>> then deciding which template to invoke will involve a serial search. By
>> contrast, if you use <xsl:choose> with a similar list of conditions, then
>> Saxon-EE will optimize this using a hash lookup.
>>
>> (b) if you use saxon:discard-document() and then subsequently read the
>> same document again, it will be read and parsed again. You should only use
>> this function if you don't expect the document to be used more than once
>> (and if you need the reclaim the memory). Using the -t option should tell
>> you what documents are being read/parsed.
>>
>> Basically, with performance issues the devil is in the detail. You
>> therefore need to supply full information: e.g. two different ways of
>> writing the same stylesheet, a representative source document, and timings
>> for both versions of the code.
>>
>> Michael Kay
>> Saxonica
>>
>>
>> On 23/06/2012 11:38, David Rudel wrote:
>>
>> Hi all,
>> I'm wondering if I'm doing something wrong because when I use
>> "<xsl:apply-templates>" rather than "<xsl:for-each>" I see a major
>> performance hit (e.g. a 40 second operation becoming 70 seconds).
>>
>> I'm wondering if it has something to do with the requirement to pass
>> variables into the new template? In particular, variables that represent
>> document nodes that are flagged with saxon:discard-document.
>>
>> For example, suppose I have a template that processes a roster of
>> employees. For each employee the template pulls up a record of the tasks the
>> employee has done, where each task is a node:
>>
>> <employee name="Bill">
>> <task type="laundry">
>> ...
>> </task>
>> <task type="dishes">
>> ...
>> </task>
>> <task type="laundry">
>> ...
>> </task>
>> ....
>> ...
>> ...
>> </employee>
>>
>> To process these tasks, data from a separate document is required. This
>> separate document is the same for each task but is specific to the employee
>> (so it doesn't make sense for that document to be a global variable).
>>
>> I may need to process several different kinds of task nodes for each
>> employee, so I need to pass this individual record to each of several
>> templates. There may be many, many different nodes that need processing, so
>> the same record is being passed dozens of times to other templates:
>>
>> <xsl:template match="/">
>> <xsl:for-each select="//employee>
>> <xsl:variable name="employeedata" select="saxon:discard-document(document
>> (...))"/>
>> <xsl:apply-templates>
>> <xsl:with-params name="employeedata" select="$employeedata"/>
>> </xsl:apply-templates>
>> </xsl:for-each>
>> </xsl:template>
>>
>> <xsl:template match="task[@type='dishes']>
>> <xsl:param name="employeedata"/>
>> ...
>> </xsl:template>
>>
>> <xsl:template match="task[@type='laundry']">
>> <xsl:param name="employeedata"/>
>> ...
>> </xsl:template>
>> ....
>> ....
>>
>> I would think that XSL processors would do everything possible to make
>> this sort of operation not significantly more CPU-intensive than a
>> completely pull-processing model where no variables need to be passed
>> anywhere.
>>
>> Is it normal to take such a performance hit using push processing? I've
>> tried various other options, like simply passing the URI to the document
>> rather than the entire document node or having the original variable be a
>> normal document and passing the saxon:discard-document version of it. These
>> approaches nearly tripled the run-time, though.
>>
>> I'm assuming that tunnel variables will not help anything here because the
>> templates I am calling do not call further templates, but perhaps my
>> understanding of tunnel variables is incomplete.
>>
>>
>>
>> --
>>
>> "A false conclusion, once arrived at and widely accepted is not dislodged
>> easily, and the less it is understood, the more tenaciously it is held." -
>> Cantor's Law of Preservation of Ignorance.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>>
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> saxon-help@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> saxon-help@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
>
>
> --
>
> "A false conclusion, once arrived at and widely accepted is not dislodged
> easily, and the less it is understood, the more tenaciously it is held." -
> Cantor's Law of Preservation of Ignorance.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help



--

"A false conclusion, once arrived at and widely accepted is not dislodged easily, and the less it is understood, the more tenaciously it is held." - Cantor's Law of Preservation of Ignorance.