我有遺留的代碼，我需要提高性能的原因。我的應用程序包含兩個需要交換某些信息的可執行文件。在遺留代碼中，一個exe寫入文件（文件名作爲參數傳遞給exe），第二個可執行文件首先檢查這個文件是否存在;如果不存在再次檢查和找到它時，則繼續讀取文件的內容。這種方式在兩個可執行文件之間傳輸信息。代碼結構化的方式，第二個可執行文件在第一次嘗試時就成功了。使用文件作爲兩個進程之間通信的手段有什麼缺點？
現在我必須清理這些代碼，並想知道使用文件作爲通信手段而不是像pipes.s一樣的進程間通信有什麼缺點是打開和閱讀比管道更昂貴的文件？還有其他的缺點嗎？你認爲這會對性能下降有多重要。
遺留代碼在Windows和Linux上運行。
使用文件IPC有些問題：
當過程（1）被寫入文件時，過程（2）發現它會發生什麼？你需要有特殊的邏輯來處理這種情況。
如果進程（1）希望在進程（2）仍在從文件讀取時發送另一個消息，會發生什麼情況？ （1）必須以某種方式檢測到文件無法寫入，並等待其可用。
文件可能成爲大消息通信量的瓶頸，尤其是如果您只爲IPC使用單個文件。
要確定文件I/O是否是您的性能瓶頸，我們需要更多地瞭解您發送的消息。他們有多大，他們發送的頻率等等。否則，很難判斷他們對你的表現有什麼影響，如果有的話。
也就是說，我已經使用過去的文件在進程之間傳遞信息，但通常每次都會創建新的文件名或者將使用文件來傳遞大量數據，並且將使用較小的IPC消息當文件準備就緒時發出信號。
在我看來，除非你有使用文件的理由 - 比如傳輸大量數據 - 我寧願使用傳統的IPC機制，比如管道，套接字等。但是你必須小心實施確保在兩個平臺上都可以正常工
我經常遇到這種類型的設置的一個問題是對文件的訪問同步，例如，如果第二個文件嘗試讀取時第一個進程仍在寫入，反之亦然。根據您的要求，這可能會導致各種不良行爲。
使用真正的IPC機制總是不錯的，但是如果你的應用必須是跨平臺的，那真的會限制你的選擇。