[poppler] performance bottleneck of SplashFont cache.

[Albert Astals Cid]

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

> 
> Thanks,
> -Sam
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler