我正在修改一个执行HFS压缩的Mac实用程序。最初，它会使用read(2)将整个文件读入内存，然后创建一个压缩的表示形式，然后将其保存到文件的扩展属性或资源派生中。该实用程序可以并行处理多个文件。
这可能会占用大量内存，因此我开始尝试使用MAP_PRIVATE来映射目标文件，我想这样做（我希望是，如果文件已被另一个进程使用（至少有时），那么mmap可能会失败。所以我有
inBuf = mmap(NULL, filesize, PROT_READ, MAP_PRIVATE|MAP_NOCACHE, 0);
代替
inBuf = malloc(filesize);
内存使用的确确实较低，但是令我惊讶的是我发现性能有所下降：处理时间明显延长，CPU负载降低和重大故障数量大大增加（根据tcsh的time实用程序）。当文件较小时，这种影响似乎更为重要，因此我设置了一个任意限制（64Mb），在该限制下使用了原始malloc + read路径。
这种权衡有一个经验法则吗？ 我可以在Linux上通过perf来运行它，但是我在Mac上知道的类似实用程序都针对GUI应用程序（当然，我的是Shell应用程序。）
编辑：考虑一下，使用mmap（）可能不会真正减少内存需求，对吗？我猜想数据仍将被复制到“快速RAM”中，而不是直接在磁盘上访问-并且您显然可以在同一文件中拥有多个独立的mmap的事实似乎支持了这一假设：
-通过将文件映射到内存中来获取文件的内容（上面的inBuf）
-我“ hfs-compress”该缓冲区，然后用压缩后的内容重写文件
-inBuf似乎没有因为重写而改变，但是随后HFS压缩文件在读取时被透明地解压缩
-我得到了现在压缩文件的新mmap，作为验证，我将其与inBuf进行了比较：内容相同。但是您还希望，如果这些mmap总是反映文件的内容，那么我不确定我的验证是否有意义。