Java 为什么PDFBox PDFRenderer速度慢？

我想使用PDFBox 2.x和PDFRender类将PDF转换为TIFF

但与ghostscript相比，它运行得非常慢

这是我的示例代码

public class SpeedTest
{
    static long startTime = System.currentTimeMillis ();

    public static void logTime (String msg)
    {
        long now = System.currentTimeMillis ();
        System.out.println (String.format ("%.3f: %s", (now - startTime) / 1000.0, msg));
        startTime = now;
    }

    public static void main (String[] args) throws Exception
    {
        //System.setProperty ("sun.java2d.cmm", "sun.java2d.cmm.kcms.KcmsServiceProvider");

        String pdfFileName = args[0];
        String tiffFileName = args[1];

        PDDocument document = PDDocument.load (new File (pdfFileName));
        logTime (pdfFileName + " loaded.");
        PDFRenderer pdfRenderer = new PDFRenderer (document);
        logTime ("intitalized renderer.");
        BufferedImage img = pdfRenderer.renderImageWithDPI (0, 600, ImageType.RGB);
        logTime ("page rendered as image.");
        ImageIO.write (img, "TIFF", new File (tiffFileName));
        logTime ("image saved as TIFF.");
    }
}

结果如下

0.521: sample.pdf loaded.
0.013: intitalized renderer.
2.910: page rendered as image.
2.005: image saved as TIFF.

如您所见，调用

pdfRenderer.renderImageWithDPI

几乎需要3秒（同样

ImageIO.write

-调用也需要2秒）

使用ghostscript执行相同操作时，整个任务将在0.4秒内完成

time gs -dQUIET -dBATCH -dNOPAUSE -sstdout=/dev/null -sDEVICE=tifflzw -r600 -dFirstPage=1 -dLastPage=1 -sOutputFile=sample.tif sample.pdf

real    0m0.389s
user    0m0.340s
sys     0m0.048s

我也试过了

System.setProperty("sun.java2d.cmm", "sun.java2d.cmm.kcms.KcmsServiceProvider");

因为我运行的是Java8（准确地说是1.8.0_161），但这没有什么区别

谢谢你的每一个想法， 问候

---

Thomas

升级至JDK 1.8.0191，于2018年10月发布或JDK 9.0.4

来自Pdfbox

PDFBox和Java 8

将PDFBox与Java 8一起使用时的重要注意事项 1.8.0¿之前或9.0.4之前的Java 9

由于java颜色管理模块向 “LittleCMS”，用户可以体验色彩的缓慢表现 操作。一个解决方案是禁用LittleCMS以支持旧的 KCMS（柯达色彩管理系统）由：

从

-Dsun.java2d.cmm=sun.java2d.cmm.kcms.kcms服务提供者开始
或者叫

资料来源：


根据我的实验，这种缓慢只发生在文档的第一个呈现页面上。如果渲染多页文档的所有页面，则第一个页面之后的所有页面渲染速度更快。渲染的绝对速度也在很大程度上取决于使用的DPI的大小

Render 6 document pages at 600 DPI
4.903s: page 0 rendered as image.
4.205s: page 1 rendered as image.
3.946s: page 2 rendered as image.
3.866s: page 3 rendered as image.
3.761s: page 4 rendered as image.
3.633s: page 5 rendered as image.

Render 6 document pages at 300 DPI
3.241s: page 0 rendered as image.
1.308s: page 1 rendered as image.
1.155s: page 2 rendered as image.
1.156s: page 3 rendered as image.
1.109s: page 4 rendered as image.
1.083s: page 5 rendered as image.

Render 6 document pages at 150 DPI
2.507s: page 0 rendered as image.
0.555s: page 1 rendered as image.
0.386s: page 2 rendered as image.
0.373s: page 3 rendered as image.
0.410s: page 4 rendered as image.
0.361s: page 5 rendered as image.

Render 6 document pages at 72 DPI
2.455s: page 0 rendered as image.
0.333s: page 1 rendered as image.
0.213s: page 2 rendered as image.
0.190s: page 3 rendered as image.
0.175s: page 4 rendered as image.
0.171s: page 5 rendered as image.

我认为这里的问题是，AWT图形在软件中进行所有渲染，并且使用恒定的像素填充率，渲染时间与DPI值成二次比例。第一个映像的缓慢可能是一些初始化开销。（但目前这完全是胡乱猜测。）
没有解决办法。你的代码很好。java通常比C++慢。即将发布的2.0.9版本将对一些PDF文件进行速度改进，但速度永远不会像ghostscript那么快。顺便说一句，你抱怨的是
ImageIO.write
，它甚至不是PDFBox的一部分。我对它的性能感到惊讶，因为我认为“自己做这个小任务”比使用大型标准工具快得多。但后来我意识到有些地方出了问题，我对PDFBox和ImageIO（我正在使用TwelveMonkeys扩展来编写TIFF）以及Java的总体性能感到疑惑。C++与java之间的速度差将是1:10！这不可能是真的吗？感谢您的支持，并表示在编程方面一切都很好！十二只猴子非常棒，我们使用了它的一小部分。如果你能分享PDF，我可以看看java档案器。。。但对于600dpi，3秒是一个相当“好”的数字。一些简单的PDF可能会更快，但一些复杂的PDF（带有阴影）可能会慢得多。我有一些以72 dpi的速度播放超过30秒的PDF。PDF没有什么特别之处——图像和阴影也是我的第一个想法。在发布这个问题之前，我尝试了不同的例子。上面的例子来自于一封带有收件人、日期和小样本文本的标准信函，只有一种标准字体，文档中没有图像。由OpenOffice创建并导出为PDF。所以尽可能简单。我将继续使用ghostscript并生成一个系统进程，以使用java主控制程序中的gs执行渲染任务。如果PDF设计良好，所有页面中都会使用字体、图像、颜色空间等资源，因此它们会在第一个页面中打开。
Render 6 document pages at 600 DPI
4.903s: page 0 rendered as image.
4.205s: page 1 rendered as image.
3.946s: page 2 rendered as image.
3.866s: page 3 rendered as image.
3.761s: page 4 rendered as image.
3.633s: page 5 rendered as image.

Render 6 document pages at 300 DPI
3.241s: page 0 rendered as image.
1.308s: page 1 rendered as image.
1.155s: page 2 rendered as image.
1.156s: page 3 rendered as image.
1.109s: page 4 rendered as image.
1.083s: page 5 rendered as image.

Render 6 document pages at 150 DPI
2.507s: page 0 rendered as image.
0.555s: page 1 rendered as image.
0.386s: page 2 rendered as image.
0.373s: page 3 rendered as image.
0.410s: page 4 rendered as image.
0.361s: page 5 rendered as image.

Render 6 document pages at 72 DPI
2.455s: page 0 rendered as image.
0.333s: page 1 rendered as image.
0.213s: page 2 rendered as image.
0.190s: page 3 rendered as image.
0.175s: page 4 rendered as image.
0.171s: page 5 rendered as image.