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=95f3955d8254a4eaede497b6468026f608399e0a;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?
Thanks,
-Sam
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler