Issue 99928 - performance: Loading calc with charts lasts more then twice a s long as before
Summary: performance: Loading calc with charts lasts more then twice a s long as before
Alias: None
Product: General
Classification: Code
Component: chart (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: kyoshida
QA Contact: issues@graphics
Keywords: performance, regression
Depends on:
Reported: 2009-03-05 16:39 UTC by IngridvdM
Modified: 2013-02-24 21:20 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

example loading slow (939.00 KB, application/
2009-03-05 16:43 UTC, IngridvdM
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description IngridvdM 2009-03-05 16:39:31 UTC
The attached document needs more than twice as long to load since CWS
On my computer following times are necessary for the different Office versions:
dev300m39: ~18sec
CWS koheiformula02 based on dev300m39: ~48sec
ooo310m2: ~16sec
ooo310m3 (first version including the CWS): ~48sec
Comment 1 IngridvdM 2009-03-05 16:43:52 UTC
Created attachment 60752 [details]
example loading slow
Comment 2 IngridvdM 2009-03-05 16:52:39 UTC
@kohei, please have a look.
It seems to me that the data that is reported to the chart now is slightly
different. The graph looks slightly different and some first debugging also
revealed, that the values are different. As one side effect now for all data
points, shapes are generated, where in the former version only for those data
point shapes where generated that where different from their predecessor.
Is the data points order affected maybe? Another idea is that creating strings
now for all the values might be suboptimal.
Comment 3 kyoshida 2009-03-05 17:03:13 UTC
ok.  I'll take a look at that.
Comment 4 kyoshida 2009-03-06 17:40:39 UTC
@iha: just for a heads-up, I ran a detailed profiling on OOO310_m4, and my
conclusion is that the performance degradation is not caused by koheiformula02
(which simply modifies the data retrieval from Calc), but probably attributed to
the new drawinglayer that does lots of heavy lifting on meta file creation for
chart object's preview.  It's still not conclusive, and I'm still continuing to
run more analysis, but this is my initial insight.

I will give you a more detailed writeup later, to give you a more detailed
picture of what's going on at file load time.
Comment 5 IngridvdM 2009-03-09 10:23:17 UTC
@kohei, as you can see from the data I have tested the CWS koheiformula02 and
the master it is based on. The difference is there. 'Simply modifiying the data
retrieval' from Calc is what must have caused this performance degradation.
While loading the attached document break into the very end of method
AreaChart::createShapes(). Watch variabels nSkippedPoints and nCreatedPoints on
the fourth hit of the breakpoint. There is a performance optimization that skips
points in case they are equal (on given resolution) to their predecessor. Before
koheiformula02 about 2000 points were skipped and for some 5500 shapes were created.
With koheiformula02 no point is skipped anymore. Creating shapes for all data
points then takes much more time in the drawing engine (which is a separate
problem and issue of its own). But the question here is why the data is so
Comment 6 kyoshida 2009-03-09 12:53:09 UTC
@iha: ah ok.  Looking into createShapes() was the next thing I was going to
profile (which is why I said it was not conclusive because of that).  I'll look
into that.
Comment 7 kyoshida 2009-03-09 14:07:17 UTC
One difference may be that, before koheiformula02, external reference values
were all zero (on Chart4 sheet), but with koheiformula02 the values were loaded
from the cache.  The chart object on the Chart4 sheet seems to be the worst
Comment 8 kyoshida 2009-05-12 15:58:56 UTC
Ok.  I looked into createShapes() call for skipped data point counts, but there
was no difference before and after the integration of koheiformula02.  I even
checked it against DEV300_m37, and the number of skipped data points was the same.

Given all this, I have no choice but to conclude that, regrettably, this
performance issue is not related to the integration of koheiformula02.  I wish
it was because of koheiformula02, then I could have tried to fix it.  But the
evidence I've seen so far contradicts that assumption.

I still think that this is probably related to the new anti-aliasing stuff...
Comment 9 IngridvdM 2011-02-10 13:19:32 UTC
kohei, do you intent to invest into this issue any further in the future?
Comment 10 niklas.nebel 2011-02-28 16:34:59 UTC
There was a problem in 3.1, but in 3.2 and current versions the file loads in the same time as in 3.0. So we can mark this as resolved.
Comment 11 niklas.nebel 2011-02-28 16:35:30 UTC