Bug 117896 - FILESAVE, EDITING Performance of Calc become very slow after copy sheet
Summary: FILESAVE, EDITING Performance of Calc become very slow after copy sheet
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks:
 
Reported: 2018-05-30 08:10 UTC by Nelson
Modified: 2020-06-06 04:59 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
document to reproduce the issue (3.92 MB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2018-05-30 08:15 UTC, Nelson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nelson 2018-05-30 08:10:27 UTC
Description:
After calc opened a xlsx file and copied a sheet, performance became very slow in the new sheet. Calc would freeze for a few seconds when scrolled up/down. Saving file also took very long (more than 10 mins).

Tried the same with Excel 2016 and no such issue was found.

Steps to Reproduce:
1. Open the attached document.
2. Copy sheet 'KROSCEK' to the end position.
3. Try scrolling up/down, calc will freeze for a few seconds.
4. Try saving the document.

Actual Results:  
When scrolled up/down, calc will freeze for a few seconds. When the file was saved, it would take very very long to finished.

Expected Results:
Scrolling in the new sheet should be smooth. Saving file should be finished quickly.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.0.4.2 (x64)
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 4; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Comment 1 Nelson 2018-05-30 08:15:01 UTC
Created attachment 142401 [details]
document to reproduce the issue
Comment 2 Xavier Van Wijmeersch 2018-05-30 08:56:09 UTC
confirm also on linux, setting hardware to all

Version: 6.2.0.0.alpha0+
Build ID: 8f9f66e8d2bae94c1f469ffc51bdbffeba853a2b
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-29_00:00:31
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 3 Telesto 2018-05-30 21:06:25 UTC
Repro with
4.4.7.2 and with

Versie: 4.1.0.4 
Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28
Comment 4 m.a.riosv 2018-05-30 22:50:09 UTC
There are 57000 VLOOKUP and another 28500 SUMIFS in the file, the new sheet duplicate the VLOOKUPs and they need to be calculated, I think the source of the slowness.
Inserting a Pivot table with MASTER GW can obtain their resume by days easily.
I don't agree it is a bug
Comment 5 Nelson 2018-05-31 02:43:22 UTC
The same operations/calculations were also tested on Ms Office 2016, on the same machine, and no such issue was found.
So, it's still a bug for me.
Comment 6 Nelson 2018-05-31 03:39:48 UTC
Still thinking about what @m.a.riosv said earlier on the formula calculation. 
Looking at the formula, where the parameter in it is already locked to a particular sheet, does it still need to be recalculated when copying sheet ?
Comment 7 Buovjaga 2018-11-24 18:12:28 UTC
The copying takes a while, but after it is completed, the scrolling is smooth.

To be crystal clear: step 3 is done after the new sheet has appeared?

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 51e6a95757906dff8b2819a4141bf3dc7938e95f
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 24 November 2018

Version: 6.2.0.0.beta1 (x64)
Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded
Comment 8 Nelson 2018-11-26 01:24:35 UTC
(In reply to Buovjaga from comment #7)
> The copying takes a while, but after it is completed, the scrolling is
> smooth.
> 
> To be crystal clear: step 3 is done after the new sheet has appeared?
> 
> Arch Linux 64-bit
> Version: 6.3.0.0.alpha0+
> Build ID: 51e6a95757906dff8b2819a4141bf3dc7938e95f
> CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; 
> Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
> Calc: threaded
> Built on 24 November 2018
> 
> Version: 6.2.0.0.beta1 (x64)
> Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
> CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
> Locale: fi-FI (fi_FI); UI-Language: en-US
> Calc: threaded

Yes, step 3 was done after the new sheet appeared AND on the new sheet.
Comment 9 Buovjaga 2018-11-26 07:47:02 UTC
Ok, so Nelson: do you reproduce the problem with 6.2 beta https://dev-builds.libreoffice.org/pre-releases/win/x86_64/LibreOfficeDev_6.2.0.0.beta1_Win_x64.msi ?
Comment 10 Nelson 2018-11-26 10:29:06 UTC
Buovjaga, confirmed this issue does not exist in 6.2 beta. 

But compared with 6.1.0.3, 6.2 beta was much slower in the process of sheet copying. It took 144 seconds to perform copy sheet with 6.1.0.3 but 272 seconds to copy the same sheet with 6.2 beta (almost 2x).
Comment 11 Buovjaga 2018-11-27 18:25:10 UTC
Ok, added regression report to See also