A Dilluns, 23 d'agost de 2010, Paweł Wiejacha va escriure: > Hi, Hi
> as a part of 'Optimization of Open Source programs' course at my > university I wrote some patches which should improve poppler performance. > > I got 4-38% (avg. 13%) performance increase [1] which for example at my > configuration (2 GHz Core2 Duo) sometimes reduces single slide rendering > time by 1.2 second. > Some patches introduce higher memory consumption (about 9%) and make .so > file bigger (about 150KB) but this is controlled by set of #defines. > > The results of my benchmarks can be found at: > http://students.mimuw.edu.pl/~pw248348/opos/plots-tests-0_base_version_vs_1 > 2_splashxpath_modern_sort.pdf > > To improve and test poppler performance, I collected several 'random' > PDFs and measured single page rendering time. > My test framework (bash + R scripts) can be found at: > http://students.mimuw.edu.pl/~pw248348/opos/perf_tests.tar.gz so you can > run tests on different set of PDFs. > The framework simply compares two git refs and produces CPU time and > memory usage plots. See README for details. > > Below is the list of patches: > > 01_get_whole_rgb_line.patch > [GfxICCBasedColorSpace, SplashOutputDev] avoid unnecessary lcms calls Seems ok, have applied it locally and will see if it creates any regression > > 03_cal_gray_reuse_pow_computations.patch > GCC does not reuse subsequent pow() calls with the same arguments. > BTW I was considering fast but less accurate pow() implementation but I > don't know how how accurate it should be for color conversion and > anti-aliasing. Seems ok, have applied it locally and will see if it creates any regression > > 04_fast_indexed_dict_lookup.patch > Some PDFs contain large amounts (2000+) of Objects, e.g. publications > with plots (grid, samples, lines, bands, axes, legend, scales). This > results in 2000^2 strcmp() calls. > Now if Dict contains > 10 objects, object-key index is built to reduce > lookup time. Seems a good idea, but at the moment we have a policy of not using std:: so that would make the patch rejected. Will have a look to see how much we really win and if would make sense loosening that policy if the win is enough. > > 05_bigger_glyph_pixmap_cache.patch > Previously glyph cache hit rate was about 10-20%. Increasing its size 6 > times (up to 1.5 MB additional memory) results in 30-60% hit rate and > 3-12% performance increase. Seems a good idea, will have a look in the coming days. > > 06_splash_forced_inlines.patch > Sometimes GCC refuses to inline function marked as inline. IMO Splash > pipe has to be inlined so I forced gcc to do that. No idea which compiler you use but gcc 4.4.3 with -O2 inlines all/most those methods for me already > > 07_inline_lexer_calls.patch > 08_inline_parser_calls.patch > 11_flatten_lexer_and_parser.patch > Both lexer and parser calls should be inlined to avoid millions of > unnecessary calls and allow compiler to make further optimizations. > (*.so size +12KB, CPU time -8%) Will have a look at this > > 09_misc_goo_optimizations.patch > some small GooHash and GooString optimizations gcc 4.4.3 with -O2 inlines those already, no win > > 10_stream_inlines.patch > CCITTFaxStream and FlateStream inlines Will have a look at this in the coming days > > 12_splashxpath_modern_sort > using qsort() from stdlib is rather bad idea Same problem of using std:: here, will have to evaluate how big is the win to break the policy. Thanks for the patches. Albert > > You can find them at: http://students.mimuw.edu.pl/~pw248348/opos/patches/ > > Best regards, > Paweł Wiejacha. > > [1] '50% performance increase' means: 50 = 100 * > (old_cpu_time/new_cpu_time - 1) > _______________________________________________ > poppler mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
