Difference between revisions of "ODT saving performance improvement"
Line 4: | Line 4: | ||
We started a profiling of the saving performance on a current AOO build with Quantify on Windows. One document(sw_complex_100p.odt) are profiled for a save procedure. | We started a profiling of the saving performance on a current AOO build with Quantify on Windows. One document(sw_complex_100p.odt) are profiled for a save procedure. | ||
− | + | The analysis of the data should be: | |
*1.show, if the profiler output is stable and reproducible | *1.show, if the profiler output is stable and reproducible | ||
*2.identify the hotspots of the current implementation | *2.identify the hotspots of the current implementation |
Revision as of 09:20, 12 June 2012
Investigation of ODT saving performance
We started a profiling of the saving performance on a current AOO build with Quantify on Windows. One document(sw_complex_100p.odt) are profiled for a save procedure.
The analysis of the data should be:
- 1.show, if the profiler output is stable and reproducible
- 2.identify the hotspots of the current implementation
- 3.be a basis to evaluate the progress by optimization
For benchmark document: sw_complex_100p.odt, it is consisted of many graphics. Following shows the hotspots(marked in blue) in saving procedure.
From these data, we can know, SfxObjectShell::GenerateAndStoreThumbnail and SwGrfNode::SwapIn occupy too much time than expected.
For SfxObjectShell::GenerateAndStoreThumbnail, we found it will call SwFlyFrm::Paint several times, but it's unnecessary to paint thumbnail when saving.
For SwGrfNode::SwapIn, through analyzing data collected from quantify, one phenomenon is that graphic will be first swapped in, after saving, it will be swapped out. If document contains lots of graphics, it will influence saving performance immensely.