Difference between revisions of "ODT saving performance improvement"
| Line 21: | Line 21: | ||
*1.Don't paint thumbnail in saving procedure. | *1.Don't paint thumbnail in saving procedure. | ||
*2.Don't swap out and swap in graphics so frequently when saving. | *2.Don't swap out and swap in graphics so frequently when saving. | ||
| + | |||
| + | =='''Graphic Management Mechanism'''== | ||
| + | Give a brief description to solution 2. | ||
Revision as of 09:22, 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.
Solution
- 1.Don't paint thumbnail in saving procedure.
- 2.Don't swap out and swap in graphics so frequently when saving.
Graphic Management Mechanism
Give a brief description to solution 2.
