为何macOS上FIFO命名管道比匿名管道慢约8倍？

测试背景 #

在M1 Max设备上，我通过mkfifo创建FIFO命名管道，使用简单C程序和pv工具测试读写性能：

• 执行./writer | pv > /dev/null时，速度约为8 GiB/s；
• 执行./writer >> mypipe并配合pv mypipe > /dev/null时，速度仅约1 GiB/s。
  统计写入次数后，两者性能差距稳定在8倍左右。尚未在Linux上测试，也未找到macOS/darwin环境下可修改FIFO管道缓冲区大小的fcntl操作。此外已验证匿名管道在阻塞前最多可写入65536字节，测试命令：M=0; while printf A; do >&2 printf "\r$((++M)) B"; done | sleep 999。

疑问 #

1. 为何命名管道方案速度更慢？
2. 是否可通过系统级配置或文件控制提升其速度？

测试用C程序 #

#include <unistd.h>
#include <string.h>
#include <stdio.h>

int main() {
    const int size = 65536;
    char buf[size];
    memset(buf, 0, size);
    while (1) {
        if (write(1, buf, size)!= size) {
            fprintf(stderr, "bad\n");
        }
    }
    return 0;
}

解答 #

1. 命名管道速度更慢的原因 #

macOS上FIFO与匿名管道的实现机制存在核心差异：

• 调度与同步开销更高：匿名管道是父子进程直接关联的通信通道，内核针对这种场景做了调度优化，上下文切换和同步成本极低；而命名管道作为文件系统实体，读写操作需经过路径解析、权限校验，且读写进程无直接关联，内核要处理连接等待、状态维护等额外同步逻辑，增加了开销。
• 缓冲区与传输机制限制：匿名管道的缓冲区可能支持动态扩容或批量传输优化，实际可用传输窗口更大；而macOS的FIFO缓冲区大小固定，且数据传输的批量处理效率更低，导致每次IO的有效数据量少，频繁操作拉低了整体速度。
• IO路径更长：匿名管道的读写是内核内存间的直接传输，而命名管道需经过VFS（虚拟文件系统）等额外文件系统层逻辑，数据传输路径更长，增加了处理成本。

2. 提升命名管道速度的可行方案 #

macOS确实没有类似Linuxfcntl(F_SETPIPE_SZ)的管道缓冲区修改接口，但可尝试以下方法：

• 调整读写块大小：将测试程序的写入块大小从65536字节增大到128KiB或256KiB，减少系统调用次数，降低每次IO的固定开销。
• 使用非阻塞IO批量处理：给FIFO的读写文件描述符设置O_NONBLOCK标志，结合循环批量读写，减少阻塞等待时间，提升吞吐量。
• 绑定进程到CPU核心：用macOS的cpuset工具将读写进程绑定到同一CPU核心，减少跨核心调度的缓存失效和上下文切换开销。
• 优化管道存储路径：确保命名管道创建在本地磁盘，避免网络共享盘，同时减少不必要的打开/关闭操作。

建议在Linux环境做对比测试，其FIFO实现与macOS差异较大，能帮助验证是否为平台特有限制。

内容的提问来源于stack exchange，提问作者edaniels