Description: After opening the attached file (on openSuse Leap 15.0) - entering a value in a column, pressing Enter. Calc freezes for about 4 s. - entering another value in the same column -> no freeze - entering a value in another column, pressing Enter. Calc freezes again for about 4 s. - switching to table "Zusammenfassung" could take up to 22 s (depending on what editing was done before) - saving the file. Calc freezes for up to 42 s (depending on what editing was done before) Workaround: Saving the file in Excel 2007-2019 format. When using this file and when saving it back to Excel format all the freezing mentioned above does not happen. Why does Calc work well with a non-native file format, but is impressingly slow with its preferred file format? It started being slow at file saving, I think, with version 5.3.x. It seemed to get worse with increasing version number. But 6.1.3.2 seems to be somewhat faster than version 6.0.7. Steps to Reproduce: 1. open the attached ods file 2. enter password: bugReport 3. enter a value in a column, press Enter -> Calc freezes for about 4 s. 4. enter a value in another column, pressing Enter. -> Calc freezes again for about 4 s. 5. Switch to table "Zusammenfassung" -> It take up to 22 s (depending on what editing was done before) until that table is activated (it contains 7 diagrams). 6. Save the file. Calc freezes for up to 42 s (depending on what editing and table switching was done before). Actual Results: Slow response/freezing as indicated in the steps above. Expected Results: Editing shall not be hindered by noticeable delays. Saving shall be performed within 2-3 seconds. Reproducible: Always User Profile Reset: Yes Additional Info: Doing the same with version 5.4.x on Windows 10 also shows a file saving delay of around 5-6 s, but no noticeable editing delay. As mentioned above: Using a file with the same content in xlsx format works well. Also: when opening such a file in ods format as it was saved 3 years ago (don't know with what version of Calc), editing and switching to table "Zusammenfassung" works without exceptional delays. That old file was almost double in size, so I'm wondering if a decompressing/compressing is somehow causing the large delays. Version: 6.1.3.2 Build-ID: 10(Build:2) CPU-Threads: 8; BS: Linux 4.12; UI-Render: Standard; VCL: gtk3_kde5; Gebietsschema: de-DE (de_DE.UTF-8); Calc: CL
Created attachment 147484 [details] File to use as described for reproducing the bug.
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.3.0.0.alpha0+ Build ID: 3c964980da07892a02d5ac721d80558c459532d0 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-12-12_02:07:45 Locale: en-US (en_US); UI-Language: en-US Calc: threaded Opening of the file creates a big time lag and sometimes it doesn't respond.
it takes ~10 seconds to get saved in Version: 6.3.0.0.alpha0+ Build ID: 6dc36d343aeacb3d1e14ec0c847937d63f4e68a7 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded Thank you for reporting the bug. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
If it takes ~10 seconds to get saved in version 6.3.0.0.alpha0, then you have successfully reproduced the bug, although it seems somewhat faster than in my case. But such a quite simple spreadsheet and with a size of only 60 kByte should not take longer than 1-2 sec to save. Therefore I don't see the point for me to install this alpha-version and reconfirm the problem myself. If you want to see the difference: save my uploaded file as xlsx. Then open that file and try to do the same with that (e.g. do a save or switch to table "Zusammenfassung"). With this file it's most probably much faster. ods file should be expected to work at least with the same speed as xlsx.
I confirm the lags in the UI and saving compared with earlier versions. I tried to bibisect this with win32-5.3, but there were commits that made Calc crash upon saving (before the password dialog). In the 5.3 repo, I didn't really see the UI lag, but there was a noticeable CPU hit on saving comparing latest vs. oldest commit. I should probably get a callgrind of this.
Created attachment 148663 [details] Callgrind output from master I took a callgrind trace only of the trace. Meaning that I launched it with --instr-atstart=no and turned instrumentation on with "callgrind_control -i on" just before saving. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: bb30e9e591d5f9f913b3cd8fbaa3c5e412b509bd CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 23 January 2019
Created attachment 150862 [details] Perf flamegraph Several plateaus with updateSHA. I saved it with password. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 18 April 2019
*** Bug 122377 has been marked as a duplicate of this bug. ***
Blah, there is a better-researched report *** This bug has been marked as a duplicate of bug 116964 ***