Bug 133267 - Undo inserting a row above extremely slow
Summary: Undo inserting a row above extremely slow
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1 all versions
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.0.1 target:6.4.5
Keywords: bibisected, bisected, perf, regression
: 121745 131709 133244 133316 133556 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-22 08:20 UTC by Telesto
Modified: 2020-06-09 12:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (1.24 MB, application/vnd.oasis.opendocument.spreadsheet)
2020-05-22 08:20 UTC, Telesto
Details
Bibisect log (4.63 KB, text/plain)
2020-05-22 18:39 UTC, Telesto
Details
Flamegraph (28.70 KB, application/x-bzip)
2020-05-23 09:01 UTC, Julien Nabet
Details
Example file (attempt 2) (1.75 MB, application/vnd.oasis.opendocument.spreadsheet)
2020-05-28 11:29 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-22 08:20:25 UTC
Description:
Undo inserting a row above extremely slow

Steps to Reproduce:
1. Open the attached file [details]
2. Insert row above (after opening)
3. Undo CTRL+Z -> Hang

Actual Results:
Slow, 10-15 seconds

Expected Results:
Fast, instant


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 442c7b95e2ee94b66a9854d0cb22f8ecb76532c6
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
4.4.7.2

and in
4.1

but not in
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 1 Telesto 2020-05-22 08:20:41 UTC
Created attachment 161118 [details]
Example file
Comment 2 Telesto 2020-05-22 18:39:25 UTC
Created attachment 161162 [details]
Bibisect log

0a8818fa523e608d895395ff5704d659f2f72533 is the first bad commit
commit 0a8818fa523e608d895395ff5704d659f2f72533
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Fri Sep 18 11:09:46 2015 +0800

    source-hash-af86f7b26f2fafbb0fdfe24682b4700a51334d18
    
    Bibisect: This commit covers the following source commit(s) which failed to build
    794d35975a35cab2ca992c45820e771481294581
    44c5a08b46bd32f5c2344380bcc38b6d09e714bb
    433661f7fc76e82595944379b5f1739c1a275331
    ff4731fb89f3b9d394c3826ab8dbe9d77df90a5a
    59f38babd074cc0b835a5d2a1c81af013dba0deb
    cfc71668da381c3a2304b4de6288a1af82ce0752
    c86014f5c6340a97bcea600ae3bd31d5f54feebb
    3c5cc7d56f6185ea0bf7593a0cd8e73232d97ddb
    24c5c1185d5908b47605782f44a9e3c5fe1814ac
    f34620b40b94d8021637c86ceb651ec881515397
    62f119b5d1c786203448c3a208fd2a2ffd26b835
    2cf33119ab461befc7226cc532593a5435ab3167
    b1c4f952223aa208067636936a7fbc00c51eeb14
    6cbca6fc0ceee4370a962d67db362f3e22270e18
    0f18a3a4bb3a4998867995f4ca8b87dacbb2ca40
    667a112815225d65e126898add254a0903ecd34f
    cd80616ef96bce7b4180d31c9b37ea17fe7efae0
    c929a78a453e3b06fd99b213fee8587dfdd68e3e
    cc7ec4b3066d47e632ebb0478259a060d030373a
    4e8206b40d960509606d4e19012da296ab71aee8
    1f083d2d288c74ffb2ae6395d163828b2a9ce4d9
    4259df774a5785b3af7bbc92dee42ecc753b12e4
    beb1db61eeb9dd15bacc4941c2c9fcd91f6df9b6
    d3a3db0e5fd5693b14caf53e50eb564912980722
    c264a7e7176da645698c770ac50a76ce5b632efa
    6cac65cc6e89f4f36dbcca3682f08b7b5ed5b750
    c6d4a39832357b9e836c0c9903d2286bcf1a69d2
    7e44f6b6ad386572b7f017a7a66bcd68d586a329
    338a6cb6c548764ed5e4dad0ca26eb3ff8d387ab
    
    commit af86f7b26f2fafbb0fdfe24682b4700a51334d18
    Author:     Kohei Yoshida <kohei.yoshida@gmail.com>
    AuthorDate: Thu May 9 11:52:55 2013 -0400
    Commit:     Kohei Yoshida <kohei.yoshida@gmail.com>
    CommitDate: Thu May 9 13:34:37 2013 -0400
    
        Remove a patch that's no longer needed.
    
        Change-Id: Ie309848f80606432752b60fbdf34e7597308d800
Comment 4 Telesto 2020-05-22 18:44:22 UTC
@Julien
Does it make sense to CC Kohei (after conformation, of course)..
Comment 5 Durgapriyanka 2020-05-22 21:02:57 UTC
Thank you for reporting the bug. I can confirm the bug present in

Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
	

But, not in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 6 Telesto 2020-05-22 21:08:03 UTC Comment hidden (obsolete)
Comment 7 Julien Nabet 2020-05-23 09:01:11 UTC
Created attachment 161183 [details]
Flamegraph

Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
I've got a slight hanging with non enable-dbgutil build.
Comment 8 b. 2020-05-25 20:36:04 UTC
repro, ~12 sec., 

Version: 7.0.0.0.alpha1+ (x64)
Build ID: b587de60d4e6aa96238766272d94f1499b22f696
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI: en-US
Calc:
Comment 9 Telesto 2020-05-25 20:41:39 UTC
This is of course exponentially.. so filling more rows makes it really slow. 
[For people saying, only 12 seconds, who cares about that..]
Comment 10 Luboš Luňák 2020-05-28 10:27:38 UTC
My (admitedly powerful at the time) machine from 2014 can perform the undo in 4 seconds. I think it's unresonable to expect that all operations with 45k rows will be instant. I also don't see this being exponential. This is at most minor, maybe even WONTFIX.
Comment 11 Telesto 2020-05-28 11:21:51 UTC
Not sure what changed here.. but someone appears to have solved this

Fine with
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 41d8b41767032681a9897b7551f011d450e3725e
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Broken with
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 442c7b95e2ee94b66a9854d0cb22f8ecb76532c6
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
6.4.3
Comment 12 Telesto 2020-05-28 11:29:22 UTC
Created attachment 161365 [details]
Example file (attempt 2)

Spoke to soon. Slightly different file.. same steps 
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 41d8b41767032681a9897b7551f011d450e3725e
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

@b
Would you mind to re-check..
Comment 13 Luboš Luňák 2020-05-28 12:42:48 UTC
Even the new file is pretty much the same here.
Comment 14 Telesto 2020-05-28 13:19:35 UTC
(In reply to Luboš Luňák from comment #13)
> Even the new file is pretty much the same here.

Linux or Windows.. seems to make a difference once in a while..
Comment 15 Telesto 2020-05-28 14:18:57 UTC
(In reply to Telesto from comment #14)
> (In reply to Luboš Luňák from comment #13)
> > Even the new file is pretty much the same here.
> 
> Linux or Windows.. seems to make a difference once in a while..

It takes me 1:20 or so before undo is finished.. for the example 2.. on Windows with 7.1. 

Anyhow, lets wait for some conformation..
Comment 16 b. 2020-05-28 15:24:31 UTC
repro ... 

win 6.2.8.2: 2:06 minutes, 

win 7.0.0.0.a1+: 1:08 minutes, 

lin 7.0.0.0.a1+: less than 2 seconds, faster than i'd look back from the stopwatch, 

@Telesto ... besides desperation ... there is also some progress ... 

@Luboš ... as we have a nice difference between win and lin imho it's a good point to hook in, as we know: 
- the issue is 'unneccessary', 
- it can be done better, 
- comparing between the two sytems should make it easier to spot the source, 
- it would be good to solve such things fast before they produce follow ups and ugly childs ... 

thus besides it's not a killer i'd like to see it with normal priority ... 

it's up to you, i'm not a pro ...
Comment 17 Commit Notification 2020-06-01 10:42:23 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fda6ad1458fcd5087c3dde56300b9d0367af6db5

cache foreign content in win32 clipboard code (tdf#133267)

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2020-06-01 13:39:04 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/9b311cabd908c6bc9e7f7d461ee11eaf0ea6b18c

cache foreign content in win32 clipboard code (tdf#133267)

It will be available in 7.0.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Xisco Faulí 2020-06-01 13:40:45 UTC
quite an old regression, don't think we need to backport it to libreoffice-6-4
Comment 20 Luboš Luňák 2020-06-05 11:23:01 UTC
*** Bug 121745 has been marked as a duplicate of this bug. ***
Comment 21 Timur 2020-06-05 13:02:17 UTC
*** Bug 131709 has been marked as a duplicate of this bug. ***
Comment 22 Timur 2020-06-05 13:02:32 UTC
*** Bug 133244 has been marked as a duplicate of this bug. ***
Comment 23 Timur 2020-06-05 13:02:50 UTC
*** Bug 133316 has been marked as a duplicate of this bug. ***
Comment 24 b. 2020-06-05 15:02:43 UTC
confirm fix, works better with below ver., 

thanks @Luboš, 

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 75e1cf6c6ea83e65da248dab917b06feea6c18e4
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL
Comment 25 Telesto 2020-06-07 08:38:00 UTC
(In reply to Xisco Faulí from comment #19)
> quite an old regression, don't think we need to backport it to
> libreoffice-6-4

Needs a backport IMHO, it solves another issue in the process. See the duplicates
Comment 26 Xisco Faulí 2020-06-08 09:29:43 UTC
(In reply to Telesto from comment #25)
> (In reply to Xisco Faulí from comment #19)
> > quite an old regression, don't think we need to backport it to
> > libreoffice-6-4
> 
> Needs a backport IMHO, it solves another issue in the process. See the
> duplicates

Done: https://gerrit.libreoffice.org/c/core/+/95749
Comment 27 Telesto 2020-06-08 11:54:16 UTC
*** Bug 133556 has been marked as a duplicate of this bug. ***
Comment 28 Commit Notification 2020-06-09 12:44:15 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/bb96d35f4dbe8b3f13e9a67f76ddcd95fa27ad57

cache foreign content in win32 clipboard code (tdf#133267)

It will be available in 6.4.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.