在早期退出之外的小文檔上進行XSL流處理的用例？

Question

我正在研究在XSL中使用流式傳輸的用例。我知道兩種明確的情況：

答：您需要轉換一個非常大的文檔，其整個內容不能保存在內存中。 B.您只需要文檔的一小部分，並且通常「小部分」靠近頂部。然後，您可以通過提前退出節省時間。

我寫信問，如果在實踐中，存在第三實際使用案例：

C.你有一個簡單的轉換，想放棄構建XML樹所需的CPU時間。 舉個例子，假設一個商店的出貨量都存儲在以下格式的XML結構：

頂級=年

2級=月

3級=日裝運

的在裝運

4級=貨物ID

5級=個別項目

菊爲了舉例，考慮一種轉換，其目的是在「月」級別提取信息......只需要存儲在月份元素的屬性中的數據，並且不需要關於這些節點的後代的任何信息。

即使必須閱讀整個文檔，這種轉換是否有可能從流式傳輸中受益？我希望有一段時間可以獲得，因爲不需要建造樹木，但是在我有限的測試中，似乎並非如此。

我在SAXON 9.5.1.3中試過這樣一個例子，流式傳輸比非流式傳輸例子慢了20％左右。 也許執行流式處理所涉及的開銷幾乎總是會比沒有構建樹的時候更糟？ （至少在SAXON，樹木建設速度非常快）

或者我在測試中犯了一個錯誤，並且有清晰的例子說明流式更有效率，即使整個文檔都要被讀取？

Answer 1

感謝有關撒克遜的數據。我對20％的開銷並不感到驚訝。如果是60％，我不會感到驚訝。這很大程度上與實施的成熟度有關;在開始思考如何快速開始之前，完全可以實現流媒體工作。但是，如果在文檔小到可以在內存中處理的情況下它比傳統處理快得多，我會感到驚訝。這部分是因爲您可以使用流式傳輸進行的這類轉換的性能可能會受到解析和序列化成本的影響，這在任一模型中都是相同的。

我知道有很多領域有優化的空間（或者至少對於詳細的測量來發現是否有優化的空間），但優先考慮的是讓所有的工作都能夠正常運行並獲得足夠的測試機構可以嘗試優化案例，而不會引入更多的錯誤。

Answer 2

除了大文件，其他可能流的優勢 - 取決於樣式表和輸入文檔的確切特性以及您如何使用輸出 - 可能會減少延遲。也就是說，有可能比傳統的處理模型更快地開始將文檔的開始傳送到下一個處理階段（或對用戶）。例如，如果您正在生成HTML，瀏覽器可能能夠更快地將頁面移動到屏幕上。

這可能是一個優勢，在某些情況下，即使吞吐量（時間來完成處理文檔）有所降低。

我不知道關於Saxon的內部，但Xalan的長期提供其目的是使同一種折衷的「增量分析」模式;它可以在某些情況下減少延遲，但增加了一些開銷，用於跟蹤迄今爲止已解析了多少輸入，因此可能會降低吞吐量。

挑選一個有意義的應用程序的模式。工具任務...

（我會仍然喜歡看到有人拿起了IBM專利的流式優化投影概念，這是我認識到的最流行的方法，在不受限制的XSLT優化機會。可惜的是，高優先級的工作裏抽出，使之從原型到生產質量所需的資源，而我還沒有發現個人時間來嘗試科研重地版本）。