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
Created attachment 142401 [details] document to reproduce the issue
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
Repro with 4.4.7.2 and with Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28
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
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.
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 ?
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
(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.
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 ?
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).
Ok, added regression report to See also