パフォーマンスへの影響が I/O によるものであることが確実で、両方のアプリケーションを変更できない場合は、実際にできることはほとんどありません。
既存のアプリケーション コードをまったく変更しない最初のソリューション: RAM ディスクを使用します。そのファイルを共有メモリとして使用している場合は、他に変更を加えることなく実行できます。データが永続的である場合、書き込みごとに別のメディアへのバックグラウンド コピーを実行する必要がある場合があります。パフォーマンスは真の共有メモリほど良くはありませんが、少なくとも遅い I/O 操作を待つ必要はありません。
データを読み取る必要があるアプリケーションのみを変更する 2 番目のソリューション: 多くの場合、XML ファイルの解析は非常に遅くなります (特に、使用XmlDocument
していてファイルが非常に小さい場合)。この場合、 を使用XmlReader
すると、読み取りコードをより複雑にし、XPath クエリを忘れる必要がありますが、パフォーマンスは何倍も向上XmlDocument
し、ファイル サイズが大きくなっても速度が低下することはありません。
小さな (またはそれほど小さくない) 更新: 2 番目のアプリケーション (ファイルを読み取るアプリケーションだと思います) のコードを変更できる場合は、そのパフォーマンスを改善するために少し行うことができます。まず第一に、毎回ファイルを読み取らないでください。タイムスタンプを確認し、FileSystemWatcher
そのファイルなどに登録しますが、毎回ファイルを読み取ったり解析したりしません。これを行うと、一歩前進できます。ファイルが変更された場合にのみファイルを読み取り/解析し、XmlDocument
バックグラウンド (別のスレッド) で準備して、ポーリング要求で使用できるようにします。リクエストが間隔を置いて配置されている場合、応答時間が非常に短くなる場合もあります (ただしXmlDocument
、一般的なファイルの XPath クエリのパフォーマンスをプロファイルします)。
編集:ここでは、Microsoft が提供する RAM ディスクを見つけることができます。それは非常に単純でナイーブですが、通常はそれ以上のことは必要ありません。さらに、これは DDK の例であるため、ソース コードも取得できます (この場合は...ただの楽しみです)。