[
https://issues.apache.org/jira/browse/PDFBOX-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389440#comment-15389440
]
Michael Doswald commented on PDFBOX-3432:
-----------------------------------------
I agree with you, that the performance gain should be great enough to justify
code changes. But the question is also, what type of improvement you get (or
you are looking for) and how you measure it. The simple use-case I used in the
benchmark showed an improvement in execution speed, but due to the way the
IntIntMap is implemented it may as well be slower in other scenarios.
But when it comes to maps with primitive data types, I'm more concerned about
the large number of small objects that are created while using it. Of couse,
Java is optimized to generate a lot of short-lived objects, and in the
best-case scenario the JIT is able to optimize away such allocations through
escape analysis. But that does not mean that allocating objects is free.
I think my priorities may be a bit different than yours. On an embedded system
I try to reduce the number of garbage collections (even minor collections)
because GCs are way more expensive and noticable than on a desktop/server
system.
> Optimize CID to GlyphId mapping (TTF)
> -------------------------------------
>
> Key: PDFBOX-3432
> URL: https://issues.apache.org/jira/browse/PDFBOX-3432
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox
> Affects Versions: 2.0.1, 2.0.2, 2.0.3
> Environment: Ubuntu 14.04.4 LTS
> Reporter: Michael Doswald
> Priority: Trivial
> Labels: optimization, performance
> Fix For: 2.0.3, 2.1.0
>
> Attachments: PDFBOX-3432_Optimize_CID_to_GlyphId_mapping_rev1.patch,
> fontbox-benchmark-CustomMap-VS-GSCollections.zip,
> patch_for_CustomMap_VS_GSCollections_benchmark.patch,
> pdfbox-performance-PDFBOX-3432.zip
>
>
> TTF fonts map code-points (Code IDs) to glyphs. These are mappings from int
> to int. Because the JDK lacks map classes for primitive types, the code (e.g.
> in CmapSubtable) currently uses Map<Integer,Integer> for those mappings. This
> is inefficient in different ways:
> * Autoboxing/unboxing introduces a performance penalty
> * Boxing to Integer objects has a memory overhead
> * The JDK Map implementation has a big memory overhead for such simple objects
> For efficiency (execution time and memory consumption) I would propose to
> introduce a simple IntIntMap implementation which works with primitive
> integers.
--
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
