Difference between revisions of "ODT saving performance improvement"
| Line 1: | Line 1: | ||
[[Category:Performance]] | [[Category:Performance]] | ||
| − | == '''Investigation of ODT saving performance'''== | + | =='''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. | 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. | ||
| Line 17: | Line 17: | ||
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. | 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. | ||
Revision as of 09:21, 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.
