<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="sourcedocs" page="streaming" subpage="burst-mode-implementation"/>
      <!--
           Generated at 2010-10-29T18:20:48.427+01:00--><title>Saxonica: XSLT and XQuery Processing: How burst-mode streaming works</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title"
            content="Saxonica: XSLT and XQuery Processing: How burst-mode streaming works"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>How burst-mode streaming works</h1>
      <p>Where necessary, the implementation of burst-mode streaming will use multithreading. One thread (which operates as a push pipeline)
is used to read the source document and filter out the nodes selected by the path expression. The nodes are then
handed over to the main processing thread, which iterates over the selected nodes using an XPath pull pipeline.
Because multithreading is used, this facility is not used when tracing is enabled. It should also be disabled
when using a debugger (there is a method in the Configuration object to achieve this.)</p>
      <p>In cases where the entire stylesheet or query can be evaluated in "push" mode (as in the first example above), 
there is no need for multithreading: the selected nodes are written directly to the current output destination.</p>
      <p>Note that a tree is built for each selected node, and its subtree. Trees are also built for all nodes selected
by the path expression, whether or not the satisfy the filter (if they do not satisfy the filter, they will
be immediately discarded from memory). The saving in memory comes when these nodes
are processed one at a time, because each subtree can then be discarded as soon as it has been processed. There
is no benefit if the stylesheet needs to perform non-serial processing, such as sorting. There is also no benefit
if the path expression selects a node that contains most or all of the source document, for example its outermost
element.</p>
      <p>Saxon can handle expressions that select nested nodes, for example <code>//section</code> where one section
contains another. However, the need to deliver nodes in document order makes the pipeline somewhat turbulent
in such cases, increasing memory usage.</p>
      <p>Streamed processing in this way is not actually faster than conventional processing (in fact, when multithreading
is required,
it may only run at half the speed). Its big advantage is that it saves memory, thus making it possible to 
process documents that would otherwise be too large for XSLT to handle. There may also be environments
where the multithreading enables greater use of the processor capacity available. 
To run without this optimization,
either change the <code>xsl:copy-of</code> instruction to <code>xsl:sequence</code>,
or set <code>saxon:read-once</code> to "no".</p>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="streamwithiterate.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>