[
https://issues.apache.org/jira/browse/PDFBOX-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406207#comment-17406207
]
Alistair Oldfield commented on PDFBOX-5267:
-------------------------------------------
Gotcha. Makes sense.
Thanks!
> LegacyPDFStreamEngine.glyphList loaded from disk on each instantiation rather
> than static final?
> ------------------------------------------------------------------------------------------------
>
> Key: PDFBOX-5267
> URL: https://issues.apache.org/jira/browse/PDFBOX-5267
> Project: PDFBox
> Issue Type: Improvement
> Components: Text extraction
> Affects Versions: 2.0.24
> Reporter: Alistair Oldfield
> Assignee: Tilman Hausherr
> Priority: Trivial
> Labels: optimization
> Fix For: 2.0.25, 3.0.0 PDFBox
>
>
> I might be wrong on this one, but I can't seem to see how the private final
> GlyphList glyphList member of LegacyPDFStreamEngine is ever modified, however
> each instance of LegacyPDFStreamEngine has its own instance of glyphList .
> It is loaded from resources in the constructor on every instantiation,
> however, is only ever used (passed as an argument) to:
>
> {code:java}
> String unicodeMapping = font.toUnicode(code, glyphList);
>
> {code}
> which in turn, I can't seem to see that it is modified.
> An application using many instances of LegacyPDFStreamEngine (which may be a
> common use-case) would load this disk resource each time it is instantiated.
> Perhaps it can be made a static final?
>
> Apologies if I was unable to catch the reason for each instance of this list.
> If there is a reason to have a separate instance, maybe then its worth
> considering copying from a static final List in memory rather than reloading
> the same file over and over?...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
