[GSOC] ODS Styles Import Performance Work Update
daniel.dev.libreoffice at gmail.com
Fri Aug 17 14:50:59 PDT 2012
From what I understand, ScXMLImport::SetStyleToRanges was being called
for each row. For each of it's calls, the result was multiple calls to
where the time was being spent in ScMarkArray::SetMarkArea and
ScMarkArray::Search. This is from the call chain of
ScXMLImport::SetStyleToRanges's use of
My first goal was to try to reduce the number of
XMLTabelStyleContext::FillPropertySet calls by only calling it if the
current style name was different from the previous style name. This way,
if several rows have the same style, we can just keep saving the ranges
and then make one call to apply styles for all of those rows.
Unfortunately, that didn't improve performance. As far as I can tell,
it just pushed the amount of time that would have been spent on each row
into one call that took approximately the sum of all of the rows' times.
Ok, I admit I haven't tried to figure out the inner workings of
ScMarkData and ScMarkArray, but I decided maybe changing what methods we
use from those classes would help. ScCellRangesBase::GetMarkData uses
ScMarkData::MarkRangeList where we iterate through an ScRangeList that
ScCellRangesBase maintains. Each iteration causes multiple calls to
ScMarkArray::SetMarkArea and Search.
So I used ScRangeList::Combine to create an ScRange and use that range
with ScMarkData::SetMarkArea. This combined with my first goal did
improve import time by 2 or 3 seconds, but I was expecting much more!
With these code changes, callgrind output reveals to me that we are no
longer spending lots of time in ScMarkData/Array methods (or ScRangeList
for that matter). Although we were already spending time in malloc's
and free's, after these changes, we seem to spend just a little bit more
time there now.
So I wonder if this means that styles wasn't necessary this file's
biggest slow down. No doubt that converting sc style UNO calls would
help performance at least a bit. I wonder if the biggest problem now
for a file like this is xmloff because it's methods are all pretty high
up there still as far as callgrind time is concerned. (Strings,
More information about the LibreOffice