Bug 85548 - slow FILESAVE and slow to exit from editing large chart; only when name for data series spans more than one cell (ie "Name In Range")
Summary: slow FILESAVE and slow to exit from editing large chart; only when name for d...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
Whiteboard: target:5.2.0
Keywords: bibisected, bisected, perf, regression
Depends on:
Reported: 2014-10-28 09:05 UTC by John
Modified: 2016-10-25 19:08 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Testfile showing slowdown (~3000 point xy-dataset with chart) (248.51 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-10-28 09:05 UTC, John

Note You need to log in before you can comment on or make changes to this bug.
Description John 2014-10-28 09:05:34 UTC
Created attachment 108561 [details]
Testfile showing slowdown (~3000 point xy-dataset with chart)

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; 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.
Comment 1 John 2014-10-28 09:27:30 UTC
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.
Comment 2 Buovjaga 2014-11-16 19:37:47 UTC
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:
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08

Ubuntu 14.10 64-bit
Build ID: 430m0(Build:2)
Comment 3 Matthew Francis 2014-12-20 16:50:50 UTC
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

    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
        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
Comment 4 Matthew Francis 2014-12-26 03:39:21 UTC
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
 [... massive commit message trimmed for length ...]
Comment 5 Robinson Tryon (qubit) 2015-12-10 09:46:20 UTC Comment hidden (obsolete)
Comment 6 Noel Grandin 2015-12-17 09:15:40 UTC
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.
Comment 7 Commit Notification 2015-12-18 22:00:29 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 8 John 2016-04-03 09:02:23 UTC
LO 5.2.0alpha does not display the drastic slowdown reported for LO4.2.X

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...
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,
Comment 9 Buovjaga 2016-04-03 10:15:38 UTC
Thanks for testing, John! I am marking this as FIXED.

We would love to have you testing more bugs :) https://wiki.documentfoundation.org/QA