Bug 77001 - Calc slows down when selecting discontinuous rows
Summary: Calc slows down when selecting discontinuous rows
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: Cell-Management
  Show dependency treegraph
Reported: 2014-04-03 13:06 UTC by Cicciopallo
Modified: 2017-07-21 19:51 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

Calc with 2 sheet tabella and example a screenshot of tabella (124.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-04-03 13:06 UTC, Cicciopallo
two compressed screenshot with Calc frozen (130.00 KB, application/x-tar)
2014-06-03 08:40 UTC, Cicciopallo

Note You need to log in before you can comment on or make changes to this bug.
Description Cicciopallo 2014-04-03 13:06:26 UTC
Created attachment 96845 [details]
Calc with 2 sheet tabella and example a screenshot of tabella

Calc crashes when I highlight a few lines as in the attached file; tried it on linux ubuntu12.04 and W7 on different PCs
Comment 1 Julien Nabet 2014-04-03 17:21:17 UTC
On pc Debian x86-64 with master sources updated 2 days ago, I don't reproduce this.
However, memory consumption increases and above all, there's some slowing when selecting the rows.

Markus: even if I can't reproduce the crash, I think it could be an interesting test case (eg: for Valgrind and/or Callgrind), any idea?
Comment 2 Markus Mohrhard 2014-04-03 22:18:04 UTC
Marking it as performance problem.
Comment 3 m.a.riosv 2014-04-03 22:23:05 UTC
I can't reproduce the crash:
Version: Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f

What I have found is a high cpu usage while applying the background color to cells, or reselecting the same rows. I's a direct format for about 15360 cells. But no crash.
Comment 4 wendrich 2014-05-22 12:56:32 UTC

Experienced the same behavior:
Highlighting more than 5 to 8 lines using STRG makes LO respondig *VERY, VERY* slow and than nonresponding even to the attempt to close the program.

Environment:  WIN7-ultimate-x64, Intel 2-core T5500@1.77 GHz, 2 GB RAM
File:  32 KB L.O. origin calc file, single sheet, range used: A-AA/1-80 = ca. 2000 cells.

Failure: absolute identical reproduceable

No such prob. with same file in re-installed V.
Comment 5 wendrich 2014-05-22 13:09:28 UTC
This bug makes LO calc component literally unuseable.

((Now, I realized I reported this to the wrong version - (where the search lead me to). Please forgive I don't know ho to transfer))
Comment 6 Joel Madero 2014-06-01 04:14:03 UTC
I can't reproduce at all:

Ubuntu 14.04 x64
LibreOffice release

What do you mean by "highlight a few lines" do you mean just select a few rows? And of what sheet? Does it matter?
Comment 7 Cicciopallo 2014-06-03 08:29:04 UTC
I open calc with new spreadsheet, I highlight/select the first odd 30 rows (for example selecting row 1,3,5,7... etc) and calc crashes/freeze/no-respond; it's happened with version on Ubuntu12.04(64bit kernel 3.5.7, gnome3.4.2, ram 8 Gb, Hd 500Gb, processor intelcore i3 m330) windows7 home premium, windows7 professional and with portable version also.
I've installed these estension also: history master 1.1.0, language tool2.2,ooop-accessories-, ooop-templates-separated-all and unified-all, sun_odf-template-pack.

This bug makes calc unusable and forces me to dowgrade to 4.1.6
Comment 8 Cicciopallo 2014-06-03 08:40:11 UTC
Created attachment 100344 [details]
two compressed screenshot with Calc frozen
Comment 9 Joel Madero 2014-06-03 15:08:42 UTC
Comment 10 Yousuf Philips (jay) (retired) 2014-06-03 18:06:11 UTC
Thanks for the screenshots. Yes i find that LibO 4.2.4, 4.2.6 and 4.3 beta start becoming less responsiveness once i reach the 3rd or 4th odd row and if selecting rows quickly, the cpu jumps high and then the UI becomes unresponsive. Also notice that with the rows being selected, trying to scroll up and down with the mouse wheel or the scroll bar halts the app for ~20s. This doesnt happen in 4.1.6. Tested this on a blank spreadsheet and one filled with data, but couldnt get calc to crash.
Comment 11 Joel Madero 2014-06-09 17:36:58 UTC
 83a62c1c1e8e259144e489d9a1f42611eba063c3 is the first bad commit
commit 83a62c1c1e8e259144e489d9a1f42611eba063c3
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Oct 17 14:30:14 2013 +0000

    commit 022c54742e7997bf46a608f1ab0b500f2537f7f5
    Author:     Tor Lillqvist <tml@iki.fi>
    AuthorDate: Tue Jun 25 07:19:41 2013 +0300
    Commit:     Tor Lillqvist <tml@iki.fi>
    CommitDate: Tue Jun 25 07:19:41 2013 +0300
        WaE: private field 'mrCells' is not used
        Change-Id: I0ab3fabb82c839f5194b0e20eb834dd86635a609

:100644 100644 4b10c5c8ddbedca0971e0839a8acc603792a447c 483b58760a06de929b32eafde25a67466c622502 M	ccache.log
:100644 100644 54c63dd94c275598f317bb54ddfdd27aaad5d8a1 fcfaf4eddaf5f8c7a66f90a052cbf2c7473cdc9b M	commitmsg
:100644 100644 e607019f9ceabe4513be6de63f5724c67ece57f9 3e023e83e964fd4b90d7bdf45eab489c7382956c M	dev-install.log
:100644 100644 2d16d57e331ca5fab2ec46ad12fe030528c544bb 47ead046b9af75e2384d8d8f51767edfa54d5dc8 M	make.log
:040000 040000 3aaab4081e7400904dc31731c74182db7e18493c 82a20807f2d069e8294cfa6e30778214a869a341 M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
git bisect skip a043626b542eb8314218d7439534dce2fc325304
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# bad: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217
git bisect bad 1d4980621741d3050a5fe61b247c157d769988f2
# bad: [ba096f438393091574da98fe7b8e6b05182a8971] source-hash-8499e78ca03c792f4fa2650e02b519094ba0baa8
git bisect bad ba096f438393091574da98fe7b8e6b05182a8971
# bad: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f
git bisect bad 9daa289e178460daaafa4b3911031df5b8736218
# good: [69bf614869471f46413fe1d2af5976b2e6d85084] source-hash-76dea8b2db906156e77f78738a68f932a15afd4b
git bisect good 69bf614869471f46413fe1d2af5976b2e6d85084
# good: [502c05c771cd993b237febc2d8a20140fe589488] source-hash-462df4920ef50032c8f99a9db2ca34c9cc928657
git bisect good 502c05c771cd993b237febc2d8a20140fe589488
# bad: [567bfa79fb5ad4f9dfa05f0dea7666208d6129b2] source-hash-4d5fc661d37d03129b8054e494c03bed1933231d
git bisect bad 567bfa79fb5ad4f9dfa05f0dea7666208d6129b2
# good: [7d878017eaa2fc1d2eab72689a5e453622d474a2] source-hash-b139f6fedfcf3cbed0eadeb007e2155b576413d2
git bisect good 7d878017eaa2fc1d2eab72689a5e453622d474a2
# bad: [83a62c1c1e8e259144e489d9a1f42611eba063c3] source-hash-022c54742e7997bf46a608f1ab0b500f2537f7f5
git bisect bad 83a62c1c1e8e259144e489d9a1f42611eba063c3
# first bad commit: [83a62c1c1e8e259144e489d9a1f42611eba063c3] source-hash-022c54742e7997bf46a608f1ab0b500f2537f7f5
Comment 12 Markus Mohrhard 2014-12-14 17:53:44 UTC
Please don't remove whiteboard entries set by developers. That will remove thos bugs from some special lists.
Comment 13 Matthew Francis 2015-01-12 11:32:45 UTC
(Edited the title to reflect the fact that this isn't a crash but a performance issue)

It's not possible to narrow this down definitively to a single commit, as the issue started within a set of commits which were apparently not written to be compiled individually - it's somewhere in the range ac84ffb3c90bb5788608eadf2177f587021daaad..e3b91687590f08438b5a5d4eec72e634b11a8589

Possibly c008dc483f8c6840803983e7e351cec6fdd32070 is the most relevant looking

commit c008dc483f8c6840803983e7e351cec6fdd32070
Author: Kohei Yoshida <kohei.yoshida@gmail.com>
Date:   Fri May 24 11:52:18 2013 -0400

    Switch to using multi_type_vector for cell storage.
    The old style cell storage is no more.  Currently the code is buildable,
    but crashes during unit test.
    Change-Id: Ie688e22e95c7fb02b9e97b23df0fc1883a97945f
Comment 14 Charles 2015-04-17 12:39:44 UTC
Maybe this is the bug I was getting ready to report?

Mine is very simple easy to reproduce... and I think it existed in 4.1. series too...

The problem is extremely evident by doing the following:

1. Open a calc spreadsheet

2. Start selecting DISCONTIGUOUS rows

3. As you select additional rows, pause occasionally to right-click on one of the rows

4. Note that the more discontiguous rows you select, the s-l-o-w-e-r it gets to bring up the context menu.

So - is this the same bug? Or should I go open a new one?
Comment 15 Robinson Tryon (qubit) 2015-12-10 11:03:15 UTC Comment hidden (obsolete)
Comment 16 Xisco Faulí 2016-10-03 09:23:46 UTC
Adding Cc: to Kohei Yoshida
Comment 17 Dennis Francis 2017-07-21 12:27:38 UTC
Could someone try to repro this on current master please ? I'm not able to reproduce the issue with the latest.

BTW, the commit bc20c6d0f397c0c1aef6ef7d6f750c2f81af8db6 did some optimization on ScMarkData especially for full row selections. Probably that fixed the problem ?

Build ID: a976fa5f00a81ff0f006a2da73fded3825e0a7c1
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group
Comment 18 Yousuf Philips (jay) (retired) 2017-07-21 19:51:45 UTC
(In reply to Dennis Francis from comment #17)
> Could someone try to repro this on current master please ? I'm not able to
> reproduce the issue with the latest.

Yes it seems to have been resolved sometime in the 4.4 cycle.

Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: en_US.UTF-8

(In reply to Charles from comment #14)
> So - is this the same bug? Or should I go open a new one?

Wasnt able to reproduce your issue with the latest version of LibreOffice, if you are still able to repo it, file a new bug and then leave a comment here with a link to it.