Apache OpenOffice (AOO) Bugzilla – Issue 81857
Charts slow down macros
Last modified: 2008-03-12 10:17:38 UTC
Hi! I've experienced a slowdown of the macro execution speed by a factor of 10 or more when going from 2.2 to 2.3. This seems to be connected to the charts. I'm not sure whether this is a problem within the charts module or between calc and charts (too frequent updates perhaps?) so I'm posting it here. I'm sorry if I got this wrong. I've uploaded a testcase to mediafire, the link is in the URL field of this issue. The sheet has a module called "Depotzins" in which is a macro called "Rate". This function can be called by "run macro" or by clicking on the "Rate" Button, if the Toolbar is visible. It sets the field "Macro Execution time" to -1, runs, and sets it to the elapsed time. Now, on my notebook the times are like this: 2.2.1: 1s 2.3: 28s 2.3 with charts deleted: 1s. Maybe someone can look into this? Lots of Greetings! Volker
Created attachment 48429 [details] I've uploaded the file to this issue. I'ts the same file the link in the URI field points to.
There's something else. If I delete the charts, undo until the charts are back it's fast again - until I save. Then it becomes slow again. Lots of Greetings! Volker
Hi Ingrid, as discussed this onefor you. Frank
set target to 2.4 as we had done it better with the old chart
The changes on the calc cells are notified to the chart which than notifies the framework. The framework then requests a new image from the modified chart. This is why the charts are recreated and repainted after each according cell modification. There is an API to prevent the notification of changes for a while and thus do several changes at once and notify only afterwards. These are the methods lockControllers() and unlockControllers() at the interface com::sun::star::frame::XModel. I will added an according sub called 'lockCharts' to the macro in the attached example. The function does lock or unlock all charts in the spreadsheet. It is important to call lock and unlock in pairs, so be careful when using this new sub. But as far as I can see no new charts are created in this example. When you try the fixed macro which makes use of the locking API you will find it as fast or even faster in OOo 2.3 than before in OOo 2.2.
Created attachment 48710 [details] corrected macro thus charts are locked during multiple updates
->Mikhail, I am unsure whether the absolut immediate request of a new replacement image is really correct. If someone would like to make a kind of animation of the chart then the current behavior is what he needs. On the other hand normally the repaint behavior is controlled by the vcl repaint timer via invalidate call. When you replace the call UpdateReplacement() with UpdateReplacementOnDemand() in the methods EmbedEventListener_Impl::modified() and EmbedEventListener_Impl::notifyEvent() in svtools/source/misc/embedhlp.cxx you will get a fast execution of the original macro also without locking the charts explicitly. As said I am unsure whether this would be correct for visible charts, but I think at least non visible ole objects should recreate their replacement image only on demand and not for every notified change. What do you think?
I need to correct myself, the above mentioned change in embedhlp.cxx does only fasten the scenario with hidden charts. Visible charts are painted somehow animation likewise still. So this might be already the correct solution. Can we replace the according calls, or would that break something else?
Hi! I just downloaded the ods file with the workaround, put the new macro into my "real" sheet and it solves the issue for me. :-) Thanks a lot! Volker
MAV->IHA: The UpdateGraphicOnDemand() method is used for optimization to avoid double updates. In this case is can not be used directly, since the UpdateGraphic() call does also update of the EmbeddedObjectContainer replacement image repository that is used on storing. The EmbeddedObjectContainer could be adjusted to do the update before the saving, but that would affect the storing performance. So the timer solution ( as vcl does it for windows ) looks currently as the best one. Anyway it is no bug but a feature, since the current design expects immediate update of the object replacements and the script writers can explicitly lock the update mechanics. I do not expect that change be done for OOo2.4.
Hi! Obviously you all know better how many people got bitten by the slowdown and have to rewrite their code now. Thanks again for the workaround! For me, having just three macros in one sheet, it meant salvation. Lots of Greetings and thanks for a marvellous product! Volker PS: I guess I'll keep out of the discussion from now on. :-)
With the fix for issue 83708 this is fixed now as follows: When the charts are not visible the macro runs fast with and without locked controllers as the chart views are not updated. When the charts are visible during macro execution the macro runs fast only with locked controllers, because otherwise each change leads to an update of the chart view which needs some time.
fixed
->Thomas, please verify in CWS chart15.
It seems its a little bit complex; JSi will support and will verifiy this issue -> reassign to JSK CWS is chart 15
What i've found is: SO8 PU6 - bugdoc: fast - Modified doc: fast SO8 PU9 - bugdoc: very slow - Modified doc: fast CWS chart15 - bugdoc: slow - Modified doc: fast So i can confirm a tiny speed improvement. Verified.
You can see the additional speed improvement when you resize the document window thus the charts are not visible while executing the macro in the unmodified bug doc.
Close