Re: [GSOC] ODS Styles Import Performance Work Update

Hi, Kohei,

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 
XMLTabelStyleContext::FillPropertySet.

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, 
lookups, etc.)


Respectfully,
Daniel Bankston