15

さまざまな XML ツール (パーサー、バリデーター、XPath 式エバリュエーターなど) のパフォーマンスが、入力ドキュメントのサイズと複雑さによってどのように影響を受けるかを知る必要があります。CPU 時間とメモリ使用量がどのように影響を受けるかを文書化したリソースはありますか? ドキュメントのサイズはバイトですか? ノード数？また、その関係は線形、多項式、またはそれより悪いものですか?

アップデート

IEEE Computer Magazine vol 41 nr 9、2008 年 9 月の記事で、著者は 4 つの一般的な XML 解析モデル (DOM、SAX、StAX、および VTD) を調査しています。彼らはいくつかの非常に基本的なパフォーマンス テストを実行し、入力ファイルのサイズが 1 ～ 15 KB から 1 ～ 15 MB に、または約 1000 倍大きくなると、DOM パーサーのスループットが半分になることを示しています。他のモデルのスループットには大きな影響はありません。

残念ながら、ノード数/サイズの関数としてのスループット/メモリ使用量など、より詳細な調査は行われませんでした。

記事はこちら。

アップデート

この問題の正式な扱いを見つけることができませんでした。参考までに、XML ドキュメント内のノード数をドキュメントのサイズ (バイト単位) の関数として測定する実験をいくつか行いました。私は倉庫管理システムに取り組んでおり、XML ドキュメントは典型的な倉庫ドキュメント (事前出荷通知など) です。

以下のグラフは、バイト単位のサイズとノード数の関係を示しています (これは、DOM モデルでのドキュメントのメモリ フットプリントに比例するはずです)。さまざまな色は、さまざまな種類のドキュメントに対応しています。スケールは log/log です。黒い線は青い点に最適です。興味深いことに、すべての種類のドキュメントで、バイト サイズとノード サイズの関係は直線的ですが、比例係数は大きく異なる可能性があります。

ベンチマーク-bytes_vs_nodes
(ソース: flickr.com )

4

4 に答える 4

3

私がその問題に直面し、グーグルで何も見つけられなかった場合、私はおそらく自分でやろうとするでしょう.

それがどこに向かっているのかを感じるためのいくつかの「裏話」のもの。しかし、xmlパーサーを実行する方法についてのアイデアが必要です。非アルゴリズムのベンチマークについては、こちらをご覧ください。

于 2008-08-28T08:21:00.880 に答える
1

ロブウォーカーは正しいです：問題は十分に詳細に特定されていません。パーサーだけを考えると（そしてそれらが検証を実行するかどうかの問題を無視して）、2つの主なフレーバーがあります。ツリーベース（DOMを考える）とストリーミング/イベントベース（ SAX（プッシュ）およびStAX（プル）を考える）です。非常に一般的に言えば、ツリーベースのアプローチはより多くのメモリを消費し、速度が遅くなりますが（ドキュメント全体の解析を完了する必要があるため）、ストリーミング/イベントベースのアプローチはより少ないメモリを消費し、より高速になります。ツリーベースのパーサーは一般的に使いやすいと考えられていますが、StAXはSAXよりも（使いやすさの点で）大幅に改善されていると言われています。

于 2008-09-03T11:47:52.880 に答える
1

多くの仮定をしない限り、単純な複雑さの指標を考え出すにはあまりにも多くの変数が関係していると思います。

単純な SAX スタイルのパーサーは、ドキュメント サイズに関しては線形であり、メモリに関してはフラットでなければなりません。

XPath 式の複雑さが大きな役割を果たすため、XPath のようなものを入力ドキュメントだけで記述することは不可能です。

同様に、スキーマ検証の場合、大規模で単純なスキーマは線形である可能性がありますが、より複雑な構造を持つ小規模なスキーマは実行時のパフォーマンスが低下します。

ほとんどのパフォーマンスに関する質問と同様に、正確な回答を得る唯一の方法は、パフォーマンスを測定して何が起こるかを確認することです!

于 2008-08-29T18:54:05.707 に答える
0

アプリケーションに非常に大きなXMLファイルをロードすることを計画していました。ここで、Stack Overflow：非常に大きなドキュメントの可能な限り最速のXML処理について質問しました 。

そして、はい、それは構文解析の部分であり、それがボトルネックでした。

結局、XMLパーサーをまったく使用しなくなりました。代わりに、速度を最適化して、可能な限り効率的に文字を1つずつ解析しました。これにより、内部データ構造の読み取り、解析、およびロードのために、3 GHzWindowsPCで毎秒40MBの速度が得られました。

さまざまなXML解析モードがこれとどのように比較されるかを聞いて非常に興味があります。

于 2009-01-12T17:44:30.063 に答える