Impress/Performance/OpenDocument

From Apache OpenOffice Wiki
Jump to: navigation, search

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.


Results analyzing load of "20_reallife_07.odp" with vtune

On vtune there is nothing that realy sticks out. Some points that are above my personal 5% threshold. Sorted per module by cpu cycles spend in module.

svtools

All in all, svtools is the high scorer during load. Most time is spend in SfxItemSet class.

  • SfxItemSet::GetItemStatet looks like it takes a lot of time and it is used inside any SfxItemSet::Get
  • SfxItemPropertySetInfo::hasPropertyByName Oliver Specht already has some ideas to switch this from linear compare to hash sets.

sal

Next comes sal, most time is spend in string operation. So moving xmloff from string to fast parser looks promising. Interestingly, osl_incrementInterlockedCount and osl_decrementInterlockedCount show up again. Main cause should be use frequent use of query interface. So using interface inheritance to lessen needs for query interface seems to be a good idea.

svx

  • ImpEditEngine::CreateLines
  • CreateFont very fast but called so often, maybe we can create that on demand?
  • SvxItemPropertyMap::getPropertyMapEntry (see SfxItemPropertySetInfo::hasPropertyByName )

tools

Strings, Strings, Strings

xmloff

  • STL::hashtable<_STL::pair<rtl::OUString const ,vos::ORef<NameSpaceEntry> >,rtl::OUString,rtl::OUStringHash,_STL::_Select1st<_STL::pair<rtl::OUString const ,vos::ORef<NameSpaceEntry> > >,OUStringEqFunc,_STL::allocator<_STL::pair<rtl::OUString const ,vos::ORef<NameSpaceEntry> > > >::clear Is the only highscorer in xmloff according to vtune

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
Personal tools