Bug 122377 - FILESAVE: Password protected calc file is slower than non protected file
Summary: FILESAVE: Password protected calc file is slower than non protected file
Status: RESOLVED DUPLICATE of bug 116964
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, haveBacktrace, perf, regression
Depends on:
Blocks: Password-Protected
  Show dependency treegraph
 
Reported: 2018-12-30 08:42 UTC by lore
Modified: 2019-04-18 20:40 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Password protected file. Password is 1234 (156.04 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-12-30 08:45 UTC, lore
Details
Non password protected file (148.56 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-12-30 08:46 UTC, lore
Details
Callgrind output from master (3.82 MB, application/x-xz)
2019-01-26 18:45 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lore 2018-12-30 08:42:37 UTC
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
Comment 1 lore 2018-12-30 08:45:55 UTC
Created attachment 147896 [details]
Password protected file. Password is 1234
Comment 2 lore 2018-12-30 08:46:32 UTC
Created attachment 147897 [details]
Non password protected file
Comment 3 Durgapriyanka 2019-01-03 21:26:19 UTC
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.
Comment 4 Xisco Faulí 2019-01-16 18:37:07 UTC
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
Comment 5 Buovjaga 2019-01-26 17:34:49 UTC
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.
Comment 6 Buovjaga 2019-01-26 18:45:29 UTC
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
Comment 7 Terrence Enger 2019-01-27 01:37:50 UTC
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.
Comment 8 Buovjaga 2019-04-18 19:50:58 UTC
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 ***
Comment 9 Buovjaga 2019-04-18 20:40:41 UTC

*** This bug has been marked as a duplicate of bug 116964 ***