我是Grand Central Dispatch的忠实粉丝，我最近一直在关注dispatch_io_*系列电话。很容易看出这个API如何对网络I / O（慢速，高延迟）有用。也就是说，dispatch_io_create_with_path种的存在意味着在本地文件系统上使用。 （是的，我知道路径也可以指向远程网络文件系统上的资源，但无论如何......）在使用它时，我发现使用dispatch_io_*似乎带来了相当大的开销与使用简单的阻止I / O调用（read，write等）相比。这种减速似乎主要来自内核同步原语，用作块在队列之间来回编组。在我一直在玩的示例工作负载中（非常多的I / O界限），减速可能差到10次。首先，看起来dispatch_io永远不会成为chatty（小颗粒）I / O的胜利。
我认为，在具有单个本地物理存储卷的单个计算机的常见情况下，I / O请求将在设备级别有效地序列化。从那里，我发现自己有这两个想法：
dispatch_io的一个本地物理卷），则无法使您的磁盘更快地为您提供数据。从那里开始，我认为这个API的最佳位置可能就在中间 - 这是一个在CPU受限和I / O限制之间徘徊的工作量，但此时我有点想到自己一个角落，所以我想我会问StackOverflow。
我将接受第一个回答，它描述了具有这些前提条件的“真实世界”工作流程（即单机，单个本地物理磁盘），使用dispatch_io可以显着提高性能。
答案 0 :(得分：7)
来自本地文件系统的调度I / O的主要用例是较大文件的异步IO，或者同时读取/写入的许多文件（特别是如果可以逐步处理文件的内容）。
本地文件系统的调度I / O针对延迟的吞吐量进行了优化（例如，它在实际IO系统调用之前执行分块和建议读取，以优化通过内核和驱动程序的IO路径上的流水线和吞吐量）。
鉴于在后台线程上异步执行IO系统调用，调度IO永远不会超过使用阻塞系统调用执行的微小文件IO的延迟，特别是在没有其他IO活动正在进行时。
来自WWDC11的GCD会话详细介绍了调度I / O，并举例说明了通过直读（）系统调用实现的吞吐量改进，以便读取各种大小的文件。