Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Very slow switching to Chart Edit Mode|
|Product:||Calc||Reporter:||Rainer Bielefeld <rainerbielefeld_ooo_qa>|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||Armin.Le.Grand, elish, issues, rainerbielefeld_ooo_qa, rb.henschel|
|Issue Type:||DEFECT||Latest Confirmation in:||4.1.0-dev|
Description Rainer Bielefeld 2013-12-21 08:22:11 UTC
Steps how to reproduce with server installation of "AOO 4.1.0-Dev – English UI / English locale - [AOO410m1(Build:9750) - Rev. 1546757 - 2013-12-02]" on German WIN7 Home Premium (64bit)", own separate user profile: 1. Open <http://www.bielefeldundbuss.de/OOO_QA/sample.ods> for "Bug 123858 - Needs too much time to open document with CHART" 2. Be very very patient 3. Doubleclick Chart into white area above Legend Expected: Edit mode within 1-2 seconds Actual: Nearby 1 minute required until edit mode is active. Additional Info: --------------- (a) Performance became worse since AOO 2.0: OOo 2.0.2 OOo 3.1.1 OOo 3.3.0 AOO 3.4.0 AOO 4.0.1 AOO 4.1.0-dev LibO 220.127.116.11 4 s 8 s 8 s 20 s 31 s 58 s 18 s
Comment 1 Edwin Sharp 2013-12-22 13:43:57 UTC
One minute and twenty seconds to edit mode. AOO410m1(Build:9750) - Rev. 1551264 2013-12-17_04:10:52 - Rev. 1551455 Debian Host/Kernel/OS "aptosidbox" running Linux 3.12-4.slh.1-aptosid-amd64 x86_64 [ aptosid 2013-01 Ἑσπερίδες - kde-lite - (201305050307) ] CPU Info 2x AMD Athlon II X2 250 clocked at [ 3000.000 MHz ] Videocard Advanced Micro Devices, [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] [ ] Processes 120 | Uptime 5:04 | Memory 902.7/3960.1MB | HDD Size 500GB (8%used) | Client Shell | Infobash v3.46
Comment 2 Armin Le Grand 2014-01-20 20:46:51 UTC
Checking with debug version (some modules with debug, including SC): load ca. 40s calculating ca 13s then until UI comes up ca 7m 30s in that time 2000 assertions of the type Error: ImpBreakLine: Start >= End? From File c:/aoo/svn_trunk44/main/editeng/source/editeng/impedit3.cxx at Line 1860 closing ca 35s. @Edwin/Rainer: Any comparisions to older versions? Is it a regression?
Comment 3 Regina Henschel 2014-01-20 21:21:26 UTC
The chart has about 32000 data points. That is the same problem we had already discussed for bug 122822. There only the wrong solution was removed, but the underlying problem has not been solved.
Comment 4 Regina Henschel 2014-01-20 21:30:31 UTC
Add that time I had created two huge demo files. They still lay in http://people.apache.org/~regina/
Comment 5 Armin Le Grand 2014-01-21 00:14:29 UTC
Using VerySleepy to get an overview what might take so long... The exclusive functions are - RtlpNtEnumerateSubKey 33,86% - free 24.05% - operator new 12.20% The inclusive are - typelib_typedescription_release 64.02% - rtl_uString_new 57.75% This all includes ChartHelper::tryToGetChartContentAsPrimitive2DSequence which is called to get the BoundRect. I tried to avoid this (the BoundRect of the Chart OLE can be determined easier), but the Charts (4 of them as it seems) get loaded at visualization anyways, so this just moves the time needed. In the file itself I saw only two charts, need to check again. In principle the long time after load is the Chart OLE loading...
Comment 6 Armin Le Grand 2014-01-21 00:18:56 UTC
Thanks Regina. Thus - without reading all the descriptions - it's the sheer amount of data? Is it the load of the Chart data or the creation of the representation?
Comment 7 Armin Le Grand 2014-01-21 00:21:14 UTC
...or in short: what exactly is the 'underlying problem'?
Comment 8 Regina Henschel 2014-01-21 14:59:11 UTC
In my experiments it was the memory handling of the huge amount of data. If I exceeded a critical amount of data, I got a "bad allocation" error with crash. The limit was sensitive to the fact whether Seamonkey run parallel, and to the memory settings in Tools > Options. Other evidence: I was able to add one data series, but not two at a time in making my demo files.