[
https://issues.apache.org/jira/browse/PDFBOX-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr resolved PDFBOX-3382.
-------------------------------------
Resolution: Fixed
I believe that there are no more risks.
Re speed, SonarQube has complained about "Inconsistent synchronization of
{{org.apache.fontbox.ttf.TrueTypeFont.postScriptNames}}; locked 57% of time". I
could correct this by using the "double-check idiom for lazy initialization of
instance fields" (
http://www.oracle.com/technetwork/articles/javase/bloch-effective-08-qa-140880.html
) but {{nameToGID()}} calls {{getMaximumProfile()}}, which is again a
synchronized method :-(
The whole TrueTypeFont class might be optimized by doing less synchronization,
but the code would look very complex.
> 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
> Assignee: Tilman Hausherr
> 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: [email protected]
For additional commands, e-mail: [email protected]
