[poppler] performance bottleneck of SplashFont cache.

[Sam Liao]

On Sun, Aug 14, 2011 at 1:04 AM, Albert Astals Cid <aacid at kde.org> wrote:
> On Dissabte 13 Agost 2011 17:35:00 Sam Liao wrote:
>> Hi All,
>>
>> I tried to a perf analysis of the poppler library with the perf-test
>> program, and follwing result:
>>
>> [kernel.kallsyms] with build id
>> ebfb885c6b5fc2a5bccbb13e06f9ff8b23596ee9 not found, continuing without
>> symbols
>> # Events: 2K cycles
>> #
>> # Overhead         Command         Shared Object
>> # ........  ..............  ....................
>> ...........................................................................
>> ...........................................................................
>> ......... #
>>     30.27%       perf-test  libfreetype.so.6.6.2  [.] 0x5501d
>>
>>             --- _start
>>                 __libc_start_main
>>                 main
>>                 PdfEnginePoppler::renderBitmap(int, double, int)
>>                 PDFDoc::displayPage(OutputDev*, int, double, double,
>> int, bool, bool, bool, bool (*)(void*), void*, bool (*)(Annot*,
>> void*), void*)
>>                 Page::display(OutputDev*, double, double, int, bool,
>> bool, bool, Catalog*, bool (*)(void*), void*, bool (*)(Annot*, void*),
>> void*)
>>                 Page::displaySlice(OutputDev*, double, double, int,
>> bool, bool, int, int, int, int, bool, Catalog*, bool (*)(void*),
>> void*, bool (*)(Annot*, void*), void*)
>>                 Gfx::display(Object*, bool)
>>                 Gfx::go(bool)
>>                 Gfx::execOp(Object*, Object*, int)
>>                 Gfx::opShowSpaceText(Object*, int)
>>                 Gfx::doShowText(GooString*)
>>                 SplashOutputDev::drawChar(GfxState*, double, double,
>> double, double, double, double, unsigned int, int, unsigned int*, int)
>>
>>                |--99.76%-- Splash::fillChar(double, double, int,
>>                |SplashFont*)
>>                |
>>                |          SplashFTFont::getGlyph(int, int, int,
>>
>> SplashGlyphBitmap*, int, int, SplashClip*, SplashClipResult*)
>>
>>                |          SplashFont::getGlyph(int, int, int,
>>
>> SplashGlyphBitmap*, int, int, SplashClip*, SplashClipResult*)
>>
>>                |          SplashFTFont::makeGlyph(int, int, int,
>>
>> SplashGlyphBitmap*, int, int, SplashClip*, SplashClipResult*)
>>
>>                |          |--59.74%-- FT_Render_Glyph
>>                |          |
>>                |          |          |--99.80%-- FT_Render_Glyph_Internal
>>
>> From the result, It seems that most of the cpu time is used on the
>> SplashFTFont::makeGlyph call, after check the SplashFont.cc source, it
>> seems that it uses kind of mru algorithm to cache font,
>> but with further analysis, I found current size of cache size is much
>> small and leads to a not good cache result,. with further analysis, I
>> find that only less than 20% font is get from cache.  after resize
>>  the cache, the performance of perf-test improved over 70% (As for my
>> understanding, the mru algorithm is used for things like processor
>> cache which has feature of hot zone of code, I think
>>  this is quite different from the pdf text rendering).
>>
>> After some search, I checked the implementation of the mupdf
>> implementation, I found that in:
>> http://git.ghostscript.com/?p=mupdf.git;a=blob;f=draw/draw_glyph.c;h=95f395
>> 5d8254a4eaede497b6468026f608399e0a;hb=HEAD
>>
>> It just use a cached hash table without limited cache size. So I'd
>> like to suggest poppler to also use similar strategy for font cache.
>>
>> What's your opinion?
>
> If you send a patch we can evaluate if it really gives rendering improvements
> or not.
>
> Albert
>

Okay, I'll try come up one.

Thanks,
-Sam