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 188.8.131.52 on Mac OS 10.14.2
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
Password protected file is much slower than the same file when not password protected
I would expect both files to behave the same.
User Profile Reset: No
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
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
The password protected file is very slow and doesn't respond while saving the file after making a change. It almost crashes My Libreoffice.
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.15; Render: default;
but not in
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
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
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:
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 ***