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
Created attachment 161118 [details] Example file
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
https://cgit.freedesktop.org/libreoffice/core/log/?id=794d35975a35cab2ca992c45820e771481294581&qt=range&q=338a6cb6c548764ed5e4dad0ca26eb3ff8d387ab
@Julien Does it make sense to CC Kohei (after conformation, of course)..
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
@Durgapriyanka Thanks for all the testing.. Appreciated. However, if possible, could you update your alpha build sometime? Getting slightly old. I sometimes post rather new bugs..
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.
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:
This is of course exponentially.. so filling more rows makes it really slow. [For people saying, only 12 seconds, who cares about that..]
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.
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
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..
Even the new file is pretty much the same here.
(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..
(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..
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 ...
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.
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.
quite an old regression, don't think we need to backport it to libreoffice-6-4
*** Bug 121745 has been marked as a duplicate of this bug. ***
*** Bug 131709 has been marked as a duplicate of this bug. ***
*** Bug 133244 has been marked as a duplicate of this bug. ***
*** Bug 133316 has been marked as a duplicate of this bug. ***
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
(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
(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
*** Bug 133556 has been marked as a duplicate of this bug. ***
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.