ScInterpreter::Interpret() backtraces during ODS import

[Kohei Yoshida]

On 06/29/2012 12:20 PM, Daniel Bankston wrote:

> The last thing I worked on was avoiding recalculating row heights during
> ODS import and instead use row heights imported from the document. I
> think I cc'd you on that, but you just got back so you probably haven't
> had a chance to go through all the spam I cc'd you on. :-) It seemed
> that the row heights were being recalculated twice and then the row
> heights were also being imported. So I just changed it to where the row
> heights were being imported only. However, Eike brought up some
> interesting concerns about this change.

IIRC there was some very old weirdness wrt calculating the position and 
size of drawing objects requiring excessive calculation and 
re-calculation of row heights.  We need to take another look at this to 
see if that's still a concern since we re-worked Calc's drawing object 
handling (including cell note positions).

> While there were no bugzilla bugs directly related to ODS import
> performance, Markus did find
> https://bugs.freedesktop.org/show_bug.cgi?id=47106 which is about
> performance while calc is already running, and may be closely related to
> our discussion about ScInterpreter::Interpret() and recalculating cell
> formulas.

Yes. Calculating row heights is a very expensive operation, and while 
the bug report says it's not related to the import, the poor performance 
of row height calculation does affect both run-time and load 
performance.  I took a brief look at that many years ago, but it wasn't 
something that could be improved easily.  Having said that, maybe we 
should take another look at this since we are already on it.  Getting a 
callgrind profile data will be the first step toward addressing this.

> So I think I can work on both fdo47106 and using imported formula
> results for now, unless you guys think otherwise.

Yup, that sounds like a good plan.

Thanks,

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc