包管理器的作用，往简单了来说，无非是把对应软件包的文件放到对应的地方去。pacman，某种意义上是包管理器里面跑得最快的那个。我没有对 pacman 做性能分析，或者让它和其他包管理器来个装包大比拼，但是有许多朋友表示 pacman 比其他发行版的包管理器快。
我相信，这种感觉并不是毫无来由。 pacman 与一般的软件包管理器相比，少了两个重要功能：写入文件后 fsync 与 SAT 求解器。这两个功能一个需要 IO 等待，一个耗 CPU，而这也可能是 pacman 为什么快的原因。
fsync(2) 是系统调用，作用就是请内核把文件真的写入存储设备。否则这些数据会留在缓存或者缓冲区里面，直到内核去真的写入。这种情况下的数据被称为 dirty page，何时写入内核有自己的决策机制，通常是达到一定百分比之后再处理。用户正常关机的情况下，数据一定是完整的。但是，如果用户此后非正常关机，那么他就有可能碰上数据损坏的问题。
相对的，有些包管理器就会使用 fsync 来保证数据的写入，deb 与 rpm 都会这么做。理论上，pacman 可以使用 hook 来实现类似的作用，但是显然不是所有人都注意到了这一点，更别说配置 hook 了。所以在使用 pacman 后非正常关机有可能导致安装的软件包损坏——在“把对应软件包的文件放到对应的地方去”这件事情上的表现并不可靠，牺牲可靠性带来的优点就是速度快。
SAT 求解器属于另一个层面。SAT 求解器是求解布尔可满足性的工具。而带版本依赖关系的计算，就是一个布尔可满足性问题。虽然 pacman 能够读取版本依赖关系，但是 pacman 不支持求解版本依赖关系，它只会尝试安装最新的版本，最新版之间依赖关系不满足就直接报错。换言之，Arch 假设所有软件包都是最新并且处于相互兼容的版本。读者可能看到过一种说法，“Arch 不支持部分更新”，这也就是 pacman 这种故意功能缺失的体现。
所以，从这种层面上讲，pacman 的速度是牺牲可靠性与功能换来的。
“什么呀！许多刚刚 Syu 完毕的 Arch 人从四面八方大声惊呼道，“我们的这个包管理器，难道说不是一个好东西吗？”是的，我回答说，pacman 当然是好东西；不过，既然你们是我的好哥们（或者好姐妹，随你们选），我希望你们能喜欢我带来的这个冷知识。不过我已经好几年没有用 Arch 了，所以如果这篇文章有什么不正确的地方，还请指正。