[ https://issues.apache.org/jira/browse/PDFBOX-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337945#comment-15337945 ]
Tilman Hausherr commented on PDFBOX-3382: ----------------------------------------- I did two things: - optimized output of hex strings. This doesn't apply to the test code, but if you add "äöü" then it does - added a map for encoding. My initial idea was to add such a map in TrueTypeFont, but I didn't because I was afraid of multithreading problems Initially the 1.8 version took 4 seconds, the 2.0 version 15 seconds. That one is now down to 5 seconds. I'd be interested what your times are with your real world application. A snapshot version will be available within a few hours. > pdf creation very slow > ---------------------- > > Key: PDFBOX-3382 > URL: https://issues.apache.org/jira/browse/PDFBOX-3382 > Project: PDFBox > Issue Type: Improvement > Components: FontBox, Writing > Affects Versions: 2.0.2 > Reporter: kazu > Priority: Minor > Labels: performance > > compared to older 1.8.x versions, the new 2.0.x branch is awesomely slow. > benchmarks using a multipage document with few images and many text-lines > indiciate a performance penalty of about 1:20 compared with the old 1.8.x > branch. > profiling via VisualVM indicates that the new font handling causes this > performance drawback: > TrueTypeFont.nameToGid() [31%] > TrueTypeFont.hasGlyph() [23%] > PDFont.getWidth() [16%] > PDType1Font.encode() [9%] > is there any workaround for this? the current setup only creates about 10 > PDFs/second compared to over 200/second for the 1.8.x branch... -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org