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 ommiting the calls to ImpEditEngine::FormatAndUpdate() during load, very sleepy reviels 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 beleave 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.

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