[PDFBOX-3088] Cache glyph table to optimize concurrent access

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0.0
• Fix Version/s: 2.0.0
• Component/s: FontBox
• Labels: Optimization multithreading
• Flags: Patch
• Assignee: Tilman Hausherr
• Reporter: ccouturi
• Created: 04/Nov/15 16:36
• Updated: 17/Mar/16 19:06
• Resolved: 05/Nov/15 22:02

Description

If several threads convert several pdf to png (one thread access to a single document at a time) they are a contention on a lock in GlythTable. Jstack shows that all threads are in state blocked on the synchronized block in the getGlyph method. The lock is necessary, it's ok, but degrades performance.

This patch cache glyphs already read.
With the patch PDFBOX-3080, the follow benchmark compare 1000 pdf conversions with 1, 8, and 50 threads.

Simulation	PDF 2.0-SNAPSHOT	With this patch + PDFBOX3080
1000 conversions / 1 thread	120 s	71 s
1000 conversions / 8 threads	76 s	28 s
1000 conversions / 50 threads	81 s	33 s

Issue Links

• breaks: PDFBOX-3102 getGlyphs returns empty array now
• is related to: PDFBOX-3089 Investigate why glyph path caching does not always cache glyph accesses