Description: Dear all, I have a password protected calc file which is much slower than the same file when not password protected. You can find 2 files attached. They are exactly the same file however one is password protected (password is 1234) and the other is not. Please experience the sluggishness in the following operations for the password protected file against the other: 1. Open the file 2. Edit cell A2 of the first sheet by entering today's date 3. Save the files All these operations take more time when the file is protected by a password. I would not expect this to happen. Using LO 6.1.3.2 on Mac OS 10.14.2 Thanks Steps to Reproduce: 1.Open both files attached 2.Experience the sluggishness in the following operations for the password protected file against the other: - Open the file - Edit cell A2 of the first sheet by entering today's date - Save the files Actual Results: Password protected file is much slower than the same file when not password protected Expected Results: I would expect both files to behave the same. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.1.3.2 Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default; Locale: en-GB (en_IT.UTF-8); Calc: group threaded
Created attachment 147896 [details] Password protected file. Password is 1234
Created attachment 147897 [details] Non password protected file
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 The password protected file is very slow and doesn't respond while saving the file after making a change. It almost crashes My Libreoffice.
Reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.15; Render: default; but not in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
We need to be careful, when analysing this. The slowness of the operations seems to have different causes. First I thought to focus on the file opening and even bibisected it with Linux 50max, but then I realised the opening speed is fast with current master. Then I investigated the saving speed and bibisected with 44max. The result seems nonsensical, though, as it has to do with OpenGL: https://gerrit.libreoffice.org/plugins/gitiles/core/+/8d509d69b434bd70b61cb6eed8b8dc21707726a3%5E!/ This OpenGL window is useless The .ods document *does* have charts, however. I guess I could get a callgrind trace. It would be good to hear the results of others with 6.3 regarding file opening time.
Created attachment 148680 [details] Callgrind output from master Took a trace of file saving. Looking at it with kcachegrind, it looks like it is spending the vast amount of time in encryption stuff, which is more logical. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1a5340788639ba71725338ddc5d340b2b304f4c2 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 26 January 2019
Responding to comment 5 ... Working on debian-buster in the bibisect-linux-64-6.3 repository I see the following CPU times in seconds: master oldest ------------ ------------ open no_pass 2.76, 3.15 9.23, 8.75 save no_pass 2.92, 2.00 8.63, 8.53 open password_1234 8.02, 8.01 14.50, 14.90 save password_1234 23.07, 22.68 30.91, 30.92 These times do not correspond strictly to response time: I saw CPU usages well over 100%, and I saw CPU usage after LibreOffice repainted the Calc window.
Took a perf flamegraph of saving and the result matches bug 122060, so let's close. *** This bug has been marked as a duplicate of bug 122060 ***
*** This bug has been marked as a duplicate of bug 116964 ***