教程菜单 本页目录

表现

测试该模块相对于其他模块的性能。

如果启用缓存(默认)并使用 8 核以上机器,尤其是具有较大 L1/L2 CPU 缓存的机器,libvips 性能将更佳。

相关(解)压缩库的 I/O 限制通常会决定最大吞吐量。

竞争者

  • jimp v0.22.10 - 纯 JavaScript 图像处理。
  • imagemagick v0.1.3 - 仅支持文件系统并且“很长时间未维护”。
  • gm v1.25.0 - GraphicsMagick 的 gm 命令行实用程序的全功能包装器。
  • @squoosh/lib v0.5.3 - 图像库已转译为 WebAssembly,包含 GPLv3 代码,但“项目不再维护”。
  • @squoosh/cli v0.7.3 - @squoosh/lib 的命令行包装器,通过生成进程避免 GPLv3,但“项目不再维护”。
  • sharp v0.33.0 / libvips v8.15.0 - libvips 中的缓存已禁用,以确保公平比较。

环境

AMD64

  • AWS EC2 us-east-2 c7a.xlarge (4x AMD EPYC 9R14)
  • Ubuntu 23.10 13f233a16be2
  • Node.js 20.10.0

ARM64

  • AWS EC2 us-east-2 c7g.xlarge (4x ARM Graviton3)
  • Ubuntu 23.10 7708743264cb
  • Node.js 20.10.0

任务:JPEG

解压 2725x2225 JPEG 图像,使用 Lanczos 3 重采样(如果可用)调整为 720x588,然后以“质量”设置为 80 压缩为 JPEG。

注意:jimp 不支持 Lanczos 3,而是使用双三次重采样。

结果:JPEG (AMD64)

模块输入输出Ops/sec加速
jimpbufferbuffer0.841.0
squoosh-clifilefile1.541.8
squoosh-libbufferbuffer2.242.7
imagemagickfilefile11.7514.0
gmbufferbuffer12.6615.1
gmfilefile12.7215.1
sharpstreamstream48.3157.5
sharpfilefile51.4261.2
sharpbufferbuffer52.4162.4

结果:JPEG (ARM64)

模块输入输出Ops/sec加速
jimpbufferbuffer0.881.0
squoosh-clifilefile1.181.3
squoosh-libbufferbuffer1.992.3
gmbufferbuffer6.066.9
gmfilefile10.8112.3
imagemagickfilefile10.9512.4
sharpstreamstream33.1537.7
sharpfilefile34.9939.8
sharpbufferbuffer36.0541.0

任务:PNG

解压缩 2048x1536 RGBA PNG 图像,预乘 alpha 通道,使用 Lanczos 3 重采样(如果可用)调整大小为 720x540,取消预乘,然后使用“默认”zlib 压缩级别 6 压缩为 PNG,不使用自适应过滤。

注意:jimp 不支持预乘/取消预乘。

结果:PNG (AMD64)

模块输入输出Ops/sec加速
squoosh-clifilefile0.341.0
squoosh-libbufferbuffer0.511.5
jimpbufferbuffer3.5910.6
gmfilefile8.5425.1
imagemagickfilefile9.2327.1
sharpfilefile25.4374.8
sharpbufferbuffer25.7075.6

结果:PNG (ARM64)

模块输入输出Ops/sec加速
squoosh-clifilefile0.331.0
squoosh-libbufferbuffer0.461.4
jimpbufferbuffer3.5110.6
gmfilefile7.4722.6
imagemagickfilefile8.0624.4
sharpfilefile17.3152.5
sharpbufferbuffer17.6653.5

运行基准测试

需要 Docker。

git clone https://github.com/lovell/sharp.git
cd sharp/test/bench
./run-with-docker.sh
本页目录