[
https://issues.apache.org/jira/browse/PDFBOX-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339807#comment-15339807
]
Tilman Hausherr commented on PDFBOX-3382:
-----------------------------------------
That's the best I can do for now... If you know that you're only using a
certain type of fonts, you could optimize even more by cutting corners:
{{getStringWidth()}} calls {{encode()}} and both could be merged into something
more efficient for type1 fonts, as these are always encoded into 1 byte. But
this would be at your own risk, we want to keep the code simple and
understandable and for all type of fonts.
Please have a look at the sources... maybe you'll find something I didn't. Re
deflater, you could experiment with the settings, e.g. replace
{code}
DeflaterOutputStream out = new DeflaterOutputStream(encoded);
{code}
with
{code}
DeflaterOutputStream out = new DeflaterOutputStream(encoded, new Deflater(1),
2048);
{code}
In theory, this should be faster, but I could not confirm it.
Other things that may help making it faster:
- don't compress the content stream at all - of course the PDF will be bigger,
so this advice makes sense only if you don't keep the files, nor mail them
- If you generate the PDFont object from a file or a stream, you could keep it
for the whole document
- same for images
- in next release: if you are constructing a PDType0Font from a TrueTypeFont
object, you can don't have to reparse the font file, you can keep it as long as
you want (see PDFBOX-3337)
Btw, 10 PDFs/second (hopefully it's 20 now) isn't THAT bad... I doubt you'll be
able to mail or print these in the same time.
> 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, 2.0.3, 2.1.0
> Reporter: kazu
> Priority: Minor
> Labels: optimization, performance
> Fix For: 2.0.3, 2.1.0
>
>
> 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
