[jira] [Closed] (PDFBOX-3380) Small change to PDFSplit loop reduces memory consuption

["Tilman Hausherr (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PDFBOX-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tilman Hausherr closed PDFBOX-3380.
-----------------------------------
    Resolution: Won't Fix

I'm closing this issue, as it has become moot due to reverting the changes in PDFBOX-3280. You can use 2.0.1 or 2.0.3 (when it is released), the effects you mention should be gone. If not, please reopen this issue or create a new one.

> Small change to PDFSplit loop reduces memory consuption
> -------------------------------------------------------
>
>                 Key: PDFBOX-3380
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-3380
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Utilities
>    Affects Versions: 2.0.2
>            Reporter: Justin Lee
>            Priority: Minor
>              Labels: patch, performance
>         Attachments: splitter.patch
>
>
> I was trying to use PDFSplit to split a large scanned document into single pages.  It very quickly ran out of memory.  I poked around in the code, and it looks to me like the issue is that the splitter code tries to create an in-memory model of every single cloned page before writing them to disk.  I created a patch based off of 2.0.2 that fixes my immediate problem in case it is helpful to anybody.  All it really does is move the outer processing loop to PDFSplit so it can write to disk after each page.  This probably isn't an ideal fix, but I'm not familiar with the internals of PDFBox to do much more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org