我有遗留代码，出于性能原因需要改进。我的应用程序包含两个需要交换某些信息的可执行文件。在遗留代码中，一个 exe 写入文件（文件名作为参数传递给 exe），第二个可执行文件首先检查这样的文件是否存在；如果不存在再次检查，当它找到它时，然后继续读取文件的内容。这种方式在两个可执行文件之间传输信息。代码的结构方式，第二个可执行文件在第一次尝试时就成功了。
现在我必须清理这段代码，并且想知道使用文件作为通信手段而不是像管道这样的进程间通信有什么缺点。打开和读取文件比管道更昂贵吗？还有其他缺点吗？您认为性能下降的影响有多大。
遗留代码在 windows 和 linux 上运行。
将文件用于 IPC 的一些问题是：
当进程 (2) 找到文件时，进程 (1) 正在写入文件时会发生什么？您需要有特殊的逻辑来处理这种情况。
如果进程 (1) 希望在进程 (2) 仍在读取文件时发送另一条消息会发生什么？(1) 必须以某种方式检测到文件无法写入，然后等到它可用。
在大量消息流量下，文件可能会成为瓶颈，尤其是在您仅使用单个文件进行 IPC 时。
要确定文件 I/O 是否是您的性能瓶颈，我们需要更多地了解您发送的消息。它们有多大，它们发送的频率等。否则很难判断它们对您的性能有什么影响（如果有的话）。
也就是说，我过去曾使用文件在进程之间传递信息，尽管通常每次都会创建新的文件名，或者文件将用于传递大量数据，并且将使用较小的 IPC 消息来指示何时文件准备好了。
在我看来，除非你有理由使用文件——比如传输大量数据——我更喜欢传统的 IPC 机制，比如管道、套接字等。但是你必须仔细实施它以确保一切正常两个平台。
我经常遇到此类设置的一个问题是对文件的访问同步，例如，如果第二个文件尝试读取时第一个进程仍在写入，反之亦然。根据您的要求，这可能会导致各种不良行为。
使用真正的 IPC 机制总是很好，但如果你的应用程序必须是跨平台的，那真的会限制你的选择。