1

system.xml名前空間を使用すると、最終的なビルドのサイズが1 mb以上増加するため、ゲーム用のxmlパーサーを作成しようとしています。パーサークラスはシングルトンであり、ゲーム内でいつでもアクセスできるようになります。扱うデータ量は少ないですが、それでもパフォーマンスが気になります（ゲームなのでパフォーマンスを犠牲にするわけにはいきません）。

解析を効果的に処理する方法はありますか？ところで、私はc＃を使用していて、名前の付いたタグ<tag>がそこにある場合は、文字列を細かく分割してとを検索し<tag>てい</tag>ます。これは、文字列全体が完全に分解されるまで再帰的に続行されます。そして、結果は私が作成したギザギザのリストクラスに保存されます。

方法はありますか、メソッドを改善できますか、それともSystem.XML名前空間を使用する必要があります。

また、別の注意：xmlデータはローカルファイルからではなくサーバーからのものです。

4

3 に答える 3

5

いくつかのメモ（これはコメントである必要がありますが、長すぎます）：

  1. 私はあなたの問題を再現できませんでした。コンソールアプリケーションを使用して、への参照を追加しSystem.Xml、を作成しXmlDocument、それを使用してコンパイルしましたが、サイズの意味のある増加は見られませんでした。
  2. System.Xml.Net基本クラスライブラリの一部です。一般に、.Netを実行するすべてのマシンにあることを期待できます（msdnによると、XmlDocumentはXNAで利用できますが、ポータブルクラスライブラリでは利用できません）。
  3. フレームワークの一部である場合は、参照でCopy Local =Trueを設定していないことを確認してください。デフォルトはfalseである必要がありますが、trueの場合、900KBDLLがターゲットフォルダーにコピーされます。
  4. 誰も答えることができません-答えは非常に相対的です-どのタイプのXML（小さい？大きい？）に？どのタイプのマシンで？これらのXMLを使用して、ユーザーはどのような操作を行うのでしょうか。コードをプロファイリングすることで、これらの質問に答えることができるのはあなただけです。
  5. XmlDocumentが遅い、または大きすぎることに気付いたとしても、.Net用のXMLパーサーは無数にあります。そのうちの1つが適しているかもしれません。（.NetXDocumentにもがありますが、それも必要なSystem.Xml.dllので、そこには利益がありません）
  6. 一般に、複数の文字列の操作は低速です。あなたが説明する方法が常に刺し傷を検索して分割している場合、それは遅く聞こえます-XMLを解析するために文字列を複数回スキャンする必要があるとは思えません。
于 2012-08-06T05:59:38.983 に答える
2

特に機能が少ない場合は、より高速なXMLパーサーを作成できる可能性があります。パフォーマンスが低く、堅牢性が低い場合は、高速になるはずです。ただし、アプリケーションの一部が「XMLをサポートする」と主張しているが、部分的にしかサポートしていない場合、XMLプロデューサーがパーサーがサポートしていないものの追加を開始することを決定した場合、将来的に破損する可能性があるため、これには注意が必要です。しかし、通常のXMLパーサーはそうします。

私は前に、反対方向からこれに出くわしました。組み込みデバイスに送信したデータを拡張する必要があり、後で読み取ることができるいくつかの属性を追加することにしました。デバイスがデータを読み取れないことに気付いたとき、私たちは驚きました。パーサーは完全に自家製であり、タグを別々の行に配置する必要があり、属性が追加されると壊れてしまうため、真のXMLパーサーとはほとんど見なされないことがわかりました。

独自のパーサーをロールする場合は注意が必要です。これは、おそらく標準の.NETパーサーほど堅牢ではないため、自分が行っていることとサポートしていないことを正確に伝達することに注意してください。

于 2012-08-06T06:15:52.570 に答える
2

私はそれをしません。つまり。信頼できるツールがすでにあります。車輪の再発明をしないでください。

于 2012-08-06T05:24:20.147 に答える