パフォーマンス上の理由から改善が必要なレガシー コードがあります。私のアプリケーションは、特定の情報を交換する必要がある 2 つの実行可能ファイルで構成されています。従来のコードでは、1 つの exe がファイルに書き込み (ファイル名は引数として exe に渡されます)、2 番目の実行可能ファイルは最初にそのようなファイルが存在するかどうかを確認します。存在しない場合は再度チェックし、見つかった場合はファイルの内容を読み取ります。このようにして、2 つの実行可能ファイル間で情報が転送されます。コードが構造化されている方法では、2 番目の実行可能ファイルは最初の試行自体で成功します。
今、私はこのコードをクリーンアップする必要があり、パイプのようなプロセス間通信ではなく、ファイルを通信手段として使用することの欠点は何だろうと思っていました.ファイルを開いて読み取るのは、パイプよりも高価ですか? 他にデメリットはありますか？そして、パフォーマンスの低下はどれほど重要だと思いますか。
レガシー コードは、Windows と Linux の両方で実行されます。
IPC にファイルを使用する際の問題点は次のとおりです。
プロセス (2) がファイルを見つけたときに、プロセス (1) がファイルに書き込んでいるとどうなりますか? このケースを処理するには、特別なロジックが必要です。
プロセス (2) がまだファイルから読み込んでいる間に、プロセス (1) が別のメッセージを送信したい場合はどうなりますか? (1) ファイルに書き込めないことをどうにかして検出し、それが利用可能になるまで待つ必要があります。
大量のメッセージ トラフィックが発生すると、ファイルがボトルネックになる可能性があります。特に、IPC に 1 つのファイルしか使用していない場合はそうです。
ファイル I/O がパフォーマンスのボトルネックであるかどうかを判断するには、送信しているメッセージについてさらに理解する必要があります。それらの大きさ、送信頻度など。それ以外の場合は、パフォーマンスにどのような影響があるかを判断することは困難です。
とはいえ、私は過去にプロセス間で情報を渡すためにファイルを使用していましたが、通常は毎回新しいファイル名が作成されるか、大量のデータを渡すためにファイルが使用され、ファイルがいつ処理されるかを知らせるために小さな IPC メッセージが使用されます。準備ができています。
私の意見では、大量のデータの転送など、ファイルを使用する理由がない限り、パイプ、ソケットなどの従来の IPC メカニズムを好むでしょう。ただし、すべてが確実に機能するように、慎重に実装する必要があります両方のプラットフォーム。
このような種類のセットアップで頻繁に直面する問題の 1 つは、ファイルへのアクセスの同期です。たとえば、2 番目のファイルが読み取りを試みたときに最初のプロセスがまだ書き込み中の場合、またはその逆の場合です。要件によっては、これはあらゆる種類の悪い動作につながる可能性があります。
実際の IPC メカニズムを使用するのは常に良いことですが、アプリをクロスプラットフォームにする必要がある場合は、選択肢が本当に制限されます。