Created attachment 108561 [details] Testfile showing slowdown (~3000 point xy-dataset with chart) Hello, Given a LibreOffice CALC spreadsheet with ~3000 x-y data points in columns (attached): I create a chart (xy scatter) of the dataset, and when I edit the range pointed to for the name of the Data Series (Name In Range =...) such that this range now spans more than one cell (eg $Sheet1.$D$3:$E$3) then suddenly... the time taken for saving the file and the time taken for exiting from the chart editor mode (after trivial change) ... both suddenly jump from a few(handful) seconds previously, to a painful 30sec for the absolute simplest(!) spreadsheet or >60sec for any real-world analytical sheet. This did not used to happen with LO CALC 4.1.6, which I used up to now; but it did occur when I tried some 4.2 version a few months ago(I'm afraid I don't know the exact version I was trying out at the time --- I reverted to 4.1.6 so as to continue working) [NB operating performance is otherwise perfectly acceptable so far with 4.2.6.3; Win7 32bit; dualcore 2GHz; 2GB RAM] ## Testfile illustrating the slowdown is attached: SlowdownWhenSeriesNameSpans2Cells.ods ## In the attachment, there are data in columns B and C, an xy-scatter plot of these and a name for the data series in two cells at D3:E3 == "PrefixSpec Sample Spec". If a trivial modification is made to the chart (eg resize slightly; edit text of axis-title; etc) then exiting the chart edit mode takes ~30 seconds for me. Saving any changes to the file, also takes ~30 seconds. The inordinate slowdown is removed by editing the chart, such that the name of the data series is pointed to just one cell eg E3 == "SampleSpec"... ie<DoubleClick chart> >> Data Ranges >> Data Series >> Select 'Name' >> Range For Name >> click button to 'select data range', select cell E3 >> OK. Regards, John.
Also, I might add that the same testfile only begins to exhibit the slow chart-exit and file-saving when the number of data points in the chart increased... 1000 or 2000 seemed okay, 3000 produced the 30sec timings.
Tested by double clicking inside the chart editor, right click, Data ranges, did a small "change" (erased something and typed it back), OK, clicked on the sheet: took about 13 secs to exit the edit mode. Saving after this also took 13 secs. The times were the same on Win and Ubuntu (4.4 was crashy, so used 4.3.3). My machine is about 3x as powerful as yours. Let's set to NEW and add bibisectRequest because reproduced on Ubuntu. Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08 Ubuntu 14.10 64-bit Version: 4.3.3.2 Build ID: 430m0(Build:2)
Bibisect results from 43all: Saving the attached file jumps from ~instant to 7 seconds or so here (* on an i7 4790k, which has ridiculously fast single core speed - the save speed remains more or less unchanged after this point in history) ba6eb41acb8df58f3009920f8ab8b32a3e1b764e is the first bad commit commit ba6eb41acb8df58f3009920f8ab8b32a3e1b764e Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 01:59:31 2012 +0000 source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc commit ae4e4a11d4300f7448cb6bd170fcb034542caddc Author: Rene Engelhard <rene@debian.org> AuthorDate: Tue Nov 6 21:24:32 2012 +0100 Commit: Rene Engelhard <rene@debian.org> CommitDate: Tue Nov 6 21:24:32 2012 +0100 typo... Change-Id: I2c7968194afbcf74967cd16c639dce7de858a513 # bad: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 # good: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf git bisect start 'last40onmaster' 'last36onmaster' # good: [bf9969effb2f759d95ecbb1a688e25f75a78da16] source-hash-8638f1e72a3fe830c0e8dcc1bd847d4fb9e599ee git bisect good bf9969effb2f759d95ecbb1a688e25f75a78da16 # good: [9cf508951c0e236a3ed240ee64c95e3d23622f7c] source-hash-98a77cef93663a0ae41dcc2c2858b418aeaaa40e git bisect good 9cf508951c0e236a3ed240ee64c95e3d23622f7c # bad: [d73160956706b297f4a7043d35e229f2e8566d5f] source-hash-44b96a2fce52b6e3e683dc917fab219cf75001db git bisect bad d73160956706b297f4a7043d35e229f2e8566d5f # good: [bc687bf6bc5604c51680e798536ccbf35fa0c6b8] source-hash-1692cf6854ff7adbb2bd47f2f7ec2b3de51864f3 git bisect good bc687bf6bc5604c51680e798536ccbf35fa0c6b8 # good: [fae90325861bbddd2af90937d29d91637c96661a] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588 git bisect good fae90325861bbddd2af90937d29d91637c96661a # bad: [e5973caebe5b9637f93a4da008d76b33b9d5ff6a] source-hash-683758efb22d08a4cf211a6d985148f513da2a90 git bisect bad e5973caebe5b9637f93a4da008d76b33b9d5ff6a # bad: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc git bisect bad ba6eb41acb8df58f3009920f8ab8b32a3e1b764e # first bad commit: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
The save time changed as of the below commit. Unfortunately it's massive, and not likely to be much direct help in figuring out what caused the performance to decrease commit 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 Author: Michael Meeks <michael.meeks@suse.com> Date: Tue Oct 9 12:22:23 2012 +0100 re-base on ALv2 code. Includes (at least) relevant parts of: linecap: Reintegrating finished LineCap feature Patch contributed by Regina Henschel http://svn.apache.org/viewvc?view=revision&revision=1232507 [... massive commit message trimmed for length ...]
Migrating Whiteboard tags to Keywords: (bibisected, perf)
The problem here centers around building a property called "SequenceMapping" There is an O(n^2) algorithm at sc/source/ui/unobj/chart2uno.cxx:1984 i.e. near the bottom of ScChart2DataProvider::detectArguments sw/source/core/unocore/unochart.cxx:1298 in method SwChartDataProvider::detectArguments appears to implement a more efficient version of the same algorithm. However, the differences are too great for me too easily port it across.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe88326d35579f2c88efe96a45911affa9c9f174 sc: convert SequenceMapping O(n^2) algorithm to O(n log(n)) tdf#85548 It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
MAIN POINT TO REPORT: LO 5.2.0alpha does not display the drastic slowdown reported for LO4.2.X TEST PERFORMED: Installed "Separate Install GUI" to facilitate parallel install of LO 5.2.0alpha (as patched by Noel Grandin) see http://dev-builds.libreoffice.org/si-gui/ Thereby parallel installed LO version labelled 'master~2016-03-31', so as not to disturb working version LO 4.1.6. NOTE1: the LO>Help>About dialog in this version 5.2.0alpha says... "Version: 5.2.0.0.alpha0+ Build ID: 7a7be32e5265f897174f3880adc061dac0203f1f CPU Threads: 2; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-03-31_07:39:11 Locale: en-US (en_US)" NOTE2: My machine is the same as when first reporting this issue, except Win7pro has been 'upgraded' to Win10pro. Now=[Win10 pro 32bit; dualcore 2GHz; 2GB RAM] Ran soffice.exe in this LO5.2.0alpha, opened the testfile which I had attached here originally, ie "SlowdownWhenSeriesNameSpans2Cells.ods". Minor edit of chart eg double-click within chart, resize area... Time taken for exit from chart editor [by click on cell outside chart] is now approx as fast in LO5.2.alpha as in LO 4.1.6 --- and this the case whether the chart dataseries name spans 2 cells or 1 cell. Time to exit chart editor (after minor change): ... in LO5.2.0alpha: With data series name spans 2 cells [D3:E3] ==> 7sec With data series name spans of 1 cell [D3:D3] ==> 3sec ... in LO4.1.6: With data series name spans 2 cells ==> 13sec With data series name spans 1 cell ==> 2sec Also, times taken for FILESAVE were similar to the above 'chart-exit' times, and so the same pattern of equivalence held between 5.2.0alpha and 4.1.6 Hence LO5.2.0alpha Calc does NOT display the drastic slowdown (~60sec chart-exit or filesave) that I reported for LO4.2.X I look forward to testing an eventual release version. Felicitations to all those involved in the detective work and the patches so welcomely achieved. Please feel free to request other tests or follow-up which I would happily try to accommodate as best I could. Kindest regards, John.
Thanks for testing, John! I am marking this as FIXED. We would love to have you testing more bugs :) https://wiki.documentfoundation.org/QA