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: | |
Severity: | Normal | ||
Priority: | P3 | CC: | Armin.Le.Grand, elish, issues, rainerbielefeld_ooo_qa, rb.henschel |
Version: | 3.4.0 | Keywords: | performance |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://issues.apache.org/ooo/show_bug.cgi?id=123858 | ||
Issue Type: | DEFECT | Latest Confirmation in: | 4.1.0-dev |
Developer Difficulty: | --- |
Description
Rainer Bielefeld
2013-12-21 08:22:11 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 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? 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. Add that time I had created two huge demo files. They still lay in http://people.apache.org/~regina/ 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... 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? ...or in short: what exactly is the 'underlying problem'? 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. |