调整包含大量文件的文件夹中的图像大小时，GraphicsMagick 速度较慢 (+80k)答案

【问题标题】：GraphicsMagick slower when resizing an image in folder with lots files (+80k)调整包含大量文件的文件夹中的图像大小时，GraphicsMagick 速度较慢 (+80k)
【发布时间】：2016-11-22 19:42:21
【问题描述】：

我注意到，当我尝试调整位于包含超过 80k 个其他图像（同一级别没有子目录）的文件夹中的图像大小时，调整大小可能需要将近 2 秒。 (1.92s)

然而，同一张图片，在一个只有 10 张其他图片的文件夹中，几乎是即时的（0.02 秒）。

我正在batch 模式下对此进行测试，因为我的应用正在使用gm4java:1.1.0。
在 Windows 10 上运行
NTFS（I thought this could be an issue，运行 contig.exe，但没有变化）
GraphicsMagick 1.3.21

这是我的命令和输出：

GM> benchmark convert -size 200x200 "C:\lots-of-pics\image399.png[0]" -auto-orient -thumbnail 200x200 "C:\Users\user\AppData\Local\Temp\img-4518761374990603981.png"
Results: 1 threads 1 iter 1.94s user 1.94s total 0.514 iter/s 0.516 iter/cpu
GM> benchmark convert -size 200x200 "C:\less-pics\image399.png[0]" -auto-orient -thumbnail 200x200 "C:\Users\user\AppData\Local\Temp\img-4518761374990603981.png"
Results: 1 threads 1 iter 0.02s user 0.02s total 58.823 iter/s 64.000 iter/cpu

我在 SO 或 sourceforge 上找不到任何相关信息。任何想法为什么它这么慢？

【问题讨论】：

您是否向 GraphicsMagick 的人员提交了错误？
@alan 不，不确定这是不是一个错误。这通常是最好的方法吗？
这个问题似乎与编程无关，也没有与编程相关的答案——所以我认为这个问题对于 SO 来说是题外话。您已经观察到 GM 的意外行为，他们将是解决此问题的最佳来源。提交错误以及可重现的测试用例应该会加快该过程。
您可以尝试编写一个完全读取给定文件和基准测试的简单应用程序 - 如果仅读取文件需要更多时间，那么是的，您的文件系统有问题（也许是 @987654326 @？）。否则，如果要转换的文件旁边有很多文件，您使用的库的行为必须有所不同 - 您必须使用分析器、Sysinternals Process Monitor 或通过许多其他可能的方法进行调查。跨度>
您很惊讶 Windows 无法处理 80,000 个以 img-nnnnnnnn.png 开头的文件？

标签： windows performance graphicsmagick disk-io

【解决方案1】：

我应该先尝试一下。结果更新到最新的 GraphicsMagick 1.3.24 解决了这个问题。

无论同一文件夹中有多少其他文件，调整同一图像的大小现在都需要相同的时间。

查看release notes of 1.3.22 这可能已经修复了它，因为提到了目录中的许多文件（我找不到确切的提交）：

常规：修复了子图像路径提取时的性能问题目录中有很多文件。

【讨论】：