2 に答える
生の XML サイズとメモリ内ツリーのサイズが 3 倍に拡大することは、確かに正常です。実際は低いです。たとえば、http://dev.saxonica.com/blog/mike/2012/09/を参照してください。
ストリーミング変換は、限られたクラスの変換で可能になり始めています。たとえば、http://www.saxonica.com/documentation/sourcedocs/streaming.xmlを参照してください。しかし、ドキュメントのサイズが 5Mb しかない場合、少なくともそれ以上の証拠がなければ、それが適切なアプローチであるかどうかはわかりません。
XSLT プロセッサによるメモリ割り当てがワークロードのパフォーマンスに影響を与える重要な要因であるという結論に達したように思えますが、これが事実であるという実際の証拠はありません。たとえば、変換時間と解析時間との関係を確認するのは興味深いことです。変換コストが解析コストに比べて小さい場合があることに多くの人が驚いています。システム パフォーマンスの 1 つの側面に対処する前に、真のボトルネックが何かを突き止める必要があります。
(M. Kay が飛び込んでくると思いますが、それまでの間)
私の知る限り、XSL 変換は常にメモリ内で行われます。ストリーミング XSL トランスフォーマーの実装については知りません (XSLT では XML ツリー全体が常に「可視」であるため、それは難しいと思います)。
私たちが発見したことは、Saxon が Xalan よりも全体的にはるかに優れたパフォーマンスを持っていることです。ドキュメントの処理に費やす時間を短縮することは、同じ期間に同じ量のメモリでより多くのドキュメントを処理することによってパフォーマンスを向上させるもう 1 つの方法です。
Saxon には独自の DocumentBuilder 実装があります (持っていた?) が、Xerces の代わりにそれを使用した場合のメモリの増加には気付きませんでした。
大規模な XML ドキュメントの場合、XSL で実行する前に、(ストリーミング) マップ/リデュース アルゴリズムを使用して小さな断片に分割します。map/reduce コードは XML Dog の上にあります