Impress/Performance/OpenDocument

Phase 1: Analyze

I'm using a wntmsci12.pro build of DEV300 m41 and the document "20_reallife_07.odp" which is available in the performancetest module under "data\presentation".

Results from analyze with very sleepy

• xml import takes up nearly all of the time during load, that is as expected
• during xml import, nearly all time is taken by SvXMLImport::startElement, that is also expected
  • in SvXMLImport::startElement, SdXMLShapeContext::AddShape takes 75% and SdXMLShapeContext::SetStyle only 21%, this is interesting
    • nearly all time is spend in SdDrawPage::add
      • This is mainly used in SdPage::SetObjText (41%), SdrObject::RecalcBoundRect(37%) and SdrObject::SetStyleSheet(14%)
        • And interestingly in SdPage::SetObjText the majority is spend in SdrObject::GetCurrentBoundRect(), I think we have our first bottleneck winner :-)

After omitting the calls to ImpEditEngine::FormatAndUpdate() during load, very sleepy reveals the remaining these top scorers

• SdrObject::RecalcBoundRect
• SdrUndoGroup::Merge (this is interesting, who does undo and why is it so slow?)
• GraphicObject::GetGraphic (this is the swap in of the graphics, seems to be expected but maybe there is room for improvement)
• SdPage::onEndTextEdit (this takes lots of time and seems unreasonable, have to be investigated)
• vcl::PNGReader::~PNGReader (this is odd, whats so hefty in the destructor of the png reader?)

After the second round of testing with very sleepy I'm suspicies that it may lead to wrong conclusions looking at the "% inclusive" numbers (which are the interesting ones). I believe that f.e. if SdPage::onEndTextEdit is called one time and calls SdrObject::RecalcBoundRect than onEndTextEdit takes all the penalty from all calls to RecalcBoundRect. I have to verify this with other tools.

...

I measured the performance difference between a version that calls ImpEditEngine::FormatAndUpdate() during load and one that does not. The difference for the test document is nearly zero. So I think it is safe to assume that very sleepy does not give usable results. I will start checking with VTune.

Results analyzing GetBoundRect() with VerySleepy and callgrind

I measured loading with CLs mentioned test document today. VerySleepy and callgrind both gave hints for SdrObject::RecalcBoundRect() usages during load. Callgrind also showed that a lot of time (ca. 1/3rd) is spent on font matching un unix systems.

To check further, i disabled BoundRect calculation completetly in the debugger when the model is locked (a sign that a load is going on). And indeed, this made the import 45-50% faster in performance, so this give a very good hint. The Problem is that at the Model level, usage of BoundRects is completely wrong from a logical standpoint when looking at Model/View/Controller paradigm. BoundRects only make sense when a view and a model is given defining the visualisation size in that view taking view-dependent aspects into account. This is already prepared with Primitives and VOCs; the VOC is the place where a BoundRect makes sense and where it is already implemented.

I will now check if it would be possible to completely remove GetBoundRect from SdrObject. This evaluation will take some time, since i will need to do incompatible builds (again...) from svx for isolating code fragments with probems.

Ideas for improvement

• void SdrObject::SetOutlinerParaObject(OutlinerParaObject* pTextObject) should not call GetCurrentBoundRect() if the document is locked while loading.
• ImpEditEngine::FormatAndUpdate( EditView* pCurView ) is called very often, I think there is much redundancy
  • I talked with malte and he we now think it is save to not call FormatAndUpdate at all during load as it is only needed and already done during painting