Bug 119026 - FILEOPEN: slower loading of multiple .ODT files and more CPU hogging since LibO 5.0
Summary: FILEOPEN: slower loading of multiple .ODT files and more CPU hogging since Li...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks:
 
Reported: 2018-07-31 21:08 UTC by Telesto
Modified: 2020-05-13 03:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (629.01 KB, application/x-zip-compressed)
2018-07-31 21:09 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-07-31 21:08:48 UTC
Description:
Fileopen ODT: Opening of multiple files slower and more CPU hogging since LibO5.0

Steps to Reproduce:
1. Extract the attached zip
2. Open Writer
3. File -> Open -> Select all the files in the zip
4. Click open & monitor time & CPU usage

Actual Results:
LibO4.4.7.2 -> 12 seconds
LibO6.2.0.0 -> 27 seconds

Expected Results:
Something like Libo4.4.7.2


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.0.0.alpha0+
Build ID: 1b21ff86effe58ae368457de8fec654ba4c8edd9
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-07-30_03:13:35
Locale: nl-NL (nl_NL); Calc: CL
Comment 1 Telesto 2018-07-31 21:09:42 UTC
Created attachment 143862 [details]
Example file
Comment 2 tommy27 2018-08-01 11:46:44 UTC
hi Telesto, did you try the same with different extensions like .DOC or .DOCX?
is the performance regressione affecting all extensions or is limited to .ODT?
Comment 3 Telesto 2018-08-01 12:43:06 UTC
In reply to tommy27 from comment #2)
> hi Telesto, did you try the same with different extensions like .DOC or
> .DOCX?
> is the performance regressione affecting all extensions or is limited to
> .ODT?

I forgot to check. But yes, it's limited to ODT (checked against doc/docx)
Comment 4 Buovjaga 2018-09-01 15:43:13 UTC
I don't have 4.4. on Linux, but I got 23 secs with 6.2.

On Win 10, I got 16 secs with 6.2 and 4.4.7. Thus I am not confirming this.
Comment 5 Xisco Faulí 2018-10-17 17:31:55 UTC
Hi Telesto,
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
Comment 6 QA Administrators 2019-05-08 18:20:01 UTC Comment hidden (obsolete)
Comment 7 Telesto 2019-05-08 18:51:15 UTC
I still reproduce
Version: 6.3.0.0.alpha0+
Build ID: 91b2239783dc716bd71ce7962bfd7e341dfe4175
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-05-08_09:49:32
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded

Difference maybe a little smaller.. performance of 4.4.7.2 is slightly worse, but say 6 seconds or so..  

Slightly off topic and maybe not an objective comparison, but LibO 6.3. opens the DOC format of the same bunch of files substantial faster,  ~10 seconds compared to ~25 when saved as odt
Comment 8 Dieter 2019-10-14 11:25:30 UTC
Telesto, perhaps there is further impriovement with the actual master build. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? => NEEDINFO
Comment 9 QA Administrators 2020-04-12 03:28:03 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2020-05-13 03:51:25 UTC
Dear Telesto,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp