Apache OpenOffice (AOO) Bugzilla – Issue 99928
performance: Loading calc with charts lasts more then twice a s long as before
Last modified: 2013-02-24 21:20:49 UTC
The attached document needs more than twice as long to load since CWS koheiformula02. 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
Created attachment 60752 [details] example loading slow
@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.
ok. I'll take a look at that.
@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.
@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 different?
@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.
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 offender.
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...
kohei, do you intent to invest into this issue any further in the future?
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.
closing