[
https://issues.apache.org/jira/browse/PDFBOX-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006336#comment-17006336
]
Tilman Hausherr commented on PDFBOX-4726:
-----------------------------------------
I wonder whether this solution works in production in a reasonable time. I've
tried using a temporary file in MemoryUsageSetting and it became very slow. I
don't do cloud computing myself, but I wonder what is more expensive: more ram
or more CPU usage? Does rendering finish in a decent amount of time when
rendering your 9166x7049 scans at 200, 300 or 600 dpi?
Also, this BigBufferedImage would have to be adjusted to our own memory
management.
One good thing is that "BigBufferedImage" isn't just a 0 scored SO answer, it
comes from a real project.
> PDFRenderer uses excessive memory
> ---------------------------------
>
> Key: PDFBOX-4726
> URL: https://issues.apache.org/jira/browse/PDFBOX-4726
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Ben Manes
> Priority: Major
> Attachments: heap.png, instance.png, stacktrace.png
>
>
> {{PDFRenderer.renderImage}} uses BufferedImage with only in-memory data. This
> is uncompressed and can use excessive memory. This occurs despite setting
> \{{MemoryUsageSetting}} being configured on the document for disk space,
> which should be honored.
> This [stackoverflow answer|https://stackoverflow.com/a/53205617/19450]
> suggests using a {{WritableRaster}} backed by a temporary file. This change
> cannot be done in user code and requires updating the {{PDFRenderer}}.
> I am currently trying to track down a PDF that caused out-of-memory issues.
> From the heap dump only a few {{BufferedImages}} where in memory, but they
> took 6gb in their uncompressed data.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
