加快 GhostScript 的任何提示？答案

【问题标题】：Any tips for speeding up GhostScript?加快 GhostScript 的任何提示？
【发布时间】：2011-05-31 17:44:55
【问题描述】：

我有一个 100 页的 PDF，大约 50 MB。我正在针对它运行下面的脚本，每页大约需要 23 秒。 PDF 是纸质文档的扫描件。

gswin32.exe -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 
            -dPDFSETTINGS=/screen -sOutputFile=out4.pdf 09.pdf

有什么办法可以加快速度吗？我已经确定 -dPDFSettings=/screen 是让它如此缓慢的原因，但没有它我无法获得良好的压缩...

更新： 好的，我尝试将其更新为下面的内容。我是否正确使用了-c 30000000 setvmthreshold 部分？

gswin32.exe -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 
            -dPDFSETTINGS=/screen -dNumRenderingThreads=2 -sOutputFile=out7.pdf 
            -c 30000000 setvmthreshold -f 09.pdf

【问题讨论】：

压缩确实需要时间，请确保在开始之前尽可能缩小图像。
不幸的是，我要解决的问题是我们的数据库中已经有大约 600GB 的超大图像。我希望我可以使用 Ghostscript 减小大小，但看起来我可能会在它完成之前退休。
OCR 它，然后有更少的图像和更少的光栅，一切都变得更快:-)

标签： pdf ghostscript

【解决方案1】：

如果您在多核系统上，请使其使用多个 CPU 内核：

-dNumRenderingThreads=<number of cpus>

让它使用最多 30mb 的 RAM：

-c "30000000 setvmthreshold"

尝试禁用垃圾收集器：

-dNOGC

有关详细信息，请参阅 Ghoscript 文档中的 Improving Performance 部分。

【讨论】：

感谢@Ismail 提供的信息。我更新了我的问题以包括我为利用 RAM 和 CPU 内核而添加的内容。你能看看 RAM 部分，看看它看起来是否正确？
看起来 -c 参数需要双引号，还添加了垃圾收集器提示，请尝试给它更多 RAM 看看是否有帮助。
当我试图在我的脚本中包含-c "30000000 setvmthreshold" 的变体时，我总是得到一个无法打开初始设备，正在退出。错误。为什么？如何避免这个错误？它需要sudo权限吗？？
@nuttyaboutnatty 我认为您必须将其放在输入文件名之前并添加-f，如下所示：gs ... -c "30000000 setvmthreshold" -f input_file.pdf

【解决方案2】：

我在核心 i7 上处理 ~300 页面 PDF 并发现添加以下选项可显着提高速度：

                            %-> comments to the right 
-dNumRenderingThreads=8     % increasing up to 64 didn't make much difference
-dBandHeight=100            % didn't matter much
-dBandBufferSpace=500000000 % (500MB)
-sBandListStorage=memory    % may or may not need to be set when gs is compiled
-dBufferSpace=1000000000    % (1GB)

-c 1000000000 setnvmthreshold -f 对我来说并没有太大的不同，FWIW。

【讨论】：

您能否提示一下您可以通过这些参数将性能提高多少？您有提高 pdf->ps 转换速度的经验吗？
哇！特别是 -dBandBufferSpace=500000000 和 -dBufferSpace=1000000000 将具有大位图图形的 pdf 转换为 300 ppi png 从超过 14 分钟的蜗牛速度到仅 50 秒，以及 -dNumRenderingThreads=4的 20 秒>
通过进一步的测试，我发现在某些情况下将-dBandBufferSpace 与-dBufferSpace 设置实际上会适得其反，并且会显着减慢较大pdf 的光栅化过程。 ghostscript 文档实际上也建议这样做：“如果您只想为带区分配更多内存，以增加带区大小并提高性能，请使用 BufferSpace 参数，而不是 BandBufferSpace。”

【解决方案3】：

你没有说你的电脑配备了什么 CPU 和多少 RAM。

你的情况是这样的：

PDF 格式的扫描文档，平均每页大小约为 500 kB。这意味着每一页基本上都是一张图片，使用扫描分辨率（至少 200 dpi，甚至可能 600 dpi）。
您正在使用 Ghostscript 重新提取它，使用 -dPDFSETTINGS=/screen。此设置将做很多事情来缩小文件大小。其中最重要的是：
1. 将所有（彩色或灰度）图像重新采样为 72dpi
2. 将所有颜色转换为 sRGB

这两种操作在 CPU 和/或 RAM 使用方面都非常“昂贵”。

顺便说一句，-dCompatibilityLevel=1.3 的设置不是必需的；它已经被-dPDFSETTINGS=/screen 隐式设置了。

试试这个：

gswin32.exe ^
 -o output.pdf ^
 -sDEVICE=pdfwrite ^
 -dPDFSETTINGS=/screen ^
 -dNumRenderingThreads=2 ^
 -dMaxPatternBitmap=1000000 ^
 -c "60000000 setvmthreshold" ^
 -f input.pdf

另外，如果您使用的是 64 位系统，请尝试安装最新的 32 位 Ghostscript 版本 (9.00)。它的性能比 64 位版本更好。

让我告诉你，将 600dpi 的扫描页面图像下采样到 72dpi 对我来说通常不需要 23 秒，但不到 1 秒。

【讨论】：

我有一个 2.79 GHz 的处理器和 3.5 GB 的内存。我试过你的方法，它仍然徘徊在20秒左右。我的文档通常是每页 750k。你能想出我可以尝试的其他方法吗？
此外，即使设置了 setvmthreshold，该进程也最多只使用 16Mb 的内存。我做错了吗？
@Abe Miessler：如果进程使用最多 16 Mb 的内存，则可能意味着它对于特定文件的需要。要仔细检查该设置是否有效，请尝试将其值设置为较低的数字，例如 200000。然后再次查看内存使用情况。
@Abe Miessler：你能排除不是I/O硬盘性能问题导致它变慢吗？（我记得以前遇到过这样的问题——我通过创建一个 ramdisk 并从 / 向 ramdisk 读取/写入文件来测试这个问题，突然性能就飙升了......）
有趣，我以前从未听说过 RAMDisk。你能推荐一个好的/免费的吗？

【解决方案4】：

我在这里可能完全不合适，但是您尝试过 Djvu 文件格式吗？总的来说，它对于扫描文档（即使有很多图片）来说就像是一种魅力，并且它提供了更好的压缩文件：我在黑白科学文章上的大小通常是无损增益的两倍。

【讨论】：

【解决方案5】：

为了加快将具有大位图图形的 pdf 光栅化为高质量 300 ppi png 图像，我发现将 -dBufferSpace 设置为尽可能高 和 -dNumRenderingThreads 设置为许多可用的内核对大多数文件最有效，-dBufferSpace 提供了最显着的提升。

效果最好的具体值是：

-dBufferSpace=2000000000 用于 2 GB 的缓冲区空间。这将一个相对较小的文件的光栅化时间从 14 分钟缩短到了 50 秒。对于较小的文件，将其设置为 1 GB 并没有太大区别，但对于较大的文件，它会产生显着差异（有时快 2 倍）。出于某种原因尝试达到 3 GB 或更高会导致启动时出现错误“不可恢复的错误：.putdeviceprops 中的范围检查”。
-dNumRenderingThreads=8 用于 8 核机器。这将同一文件的光栅化时间从 14 分钟缩短到了 4 分钟（如果使用 4 个线程，则需要 8 分钟）。将其与上面的-dBufferSpace 选项结合使用，时间从 50 秒缩短到 25 秒。然而，当与-dBufferSpace 结合使用时，随着线程数的增加，收益似乎在递减，并且对于某些文件来说几乎没有影响。奇怪的是，对于一些较大的文件，将线程数设置为 1 实际上比任何其他数字都快。

整个命令看起来像：

gs -sDEVICE=png16m -r300 -o document.png -dNumRenderingThreads=8 -dBufferSpace=2000000000 -f document.pdf

这是使用 Ghostscript 9.52 测试的，并且是在测试 @wpgalle3 的答案以及 Ghostscript 文档中的 Improving performance 部分中的建议后得出的。

文档中的一个关键要点是，当 ghostscript 由于光栅图像输出大于 -dMaxBitmap 的值而使用“条带模式”时，它可以利用多个内核来加快处理速度。

无效或适得其反的选项：

单独或与-dBufferSpace 一起设置-c "2000000000 setvmthreshold"（2 GB）似乎没有什么不同。

设置 -sBandListStorage=memory 导致分段错误。

设置-dMaxBitmap=2000000000（2 GB）显着减慢了进程，显然导致它失控，写入数百 GB 的临时文件而没有任何停止的迹象，促使我终止进程。

将-dBandBufferSpace 设置为-dBufferSpace 的一半对于较小的文件没有影响，但实际上对于较大的文件将处理速度显着减慢了 1.5-1.75 倍。在 Ghostscript 文档的 Banding parameters 部分中，实际上建议不要使用 -dBandBufferSpace：“如果您只想为 banding 分配更多内存，以增加 band 大小并提高性能，请使用 BufferSpace 参数，而不是 BandBufferSpace。”

【讨论】：