Bug 126788 - FILEOPEN: ODT big performance drop for big table from 6.1 to 6.3, 6.4, 7.0
Summary: FILEOPEN: ODT big performance drop for big table from 6.1 to 6.3, 6.4, 7.0
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: File-Opening
  Show dependency tree / graph
 
Reported: 2019-08-09 08:02 UTC by Paul
Modified: 2021-03-27 07:27 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:

Attachments
perf flamegraph (2.19 MB, image/svg+xml)
2019-08-11 09:43 UTC, Julien Nabet 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paul 2019-08-09 08:02:18 UTC 
Summary:
 6.3.0.4 appears to take 224% longer than 6.1.5.2 when loading/saving ODT from bug 84635 
 Quite the reverse of the 6.3.0.4 release documentation.

Detail:
There seems to be a big drop in performance on Windows 10 for the files attached to bug (84635).  I've raised this as a separate bug since it appears to be limited to Windows and it tests performance using LOAD and SAVE operations which may mean it has a slightly different cause.  Tests on linux show no significant improvement or degradation in performance using this test between 6.1, 6.2 and 6.3 (which is also unexpected but not a regression).

Release 6.3.0.4 touts big improvements in ODT load times (order of magnitude) and related to large tables.  It also specifically states it resolves bug 84635.

The test uses the LibreOffice command line to get the time taken to convert an ODT to PDF.

The file used is https://bugs.documentfoundation.org/attachment.cgi?id=107265 which is the second test document attached to bug (84635) and the file is called:
  table_1034r_13p.odt

On Windows, the following command is put into a batch script file conv6.1.5.2.bat:

  "\Program Files\LibreOffice6.1.5.2\program\soffice.exe" --convert-to pdf table_2178r_26p.odt --headless

and using Windows Power Shell, the execution time of the convert can be collected:

  Measure-Command {.\conv6.1.5.2.bat}

The above process was used with 6.1.5.2, 6.2.6.1 and 6.3.0.4 generating the following averaged results:

  6.1.5.2 - 31.5 seconds
  6.2.6.1 - 43.5 seconds (+38% longer)
  6.3.0.4 - 70.7 seconds (+224% longer)

Notes:
1) After looking at related bugs, the tests were executed with and without GPL enabled which did not make a significant difference.
2) The tests were also executed after clearing the user settings (%APPDATA%\Roaming\LibreOffice) so that the version being tested would create the user profile during the test.
3) Converting to docx (instead of PDF) has similar results
Comment 1 Xisco Faulí 2019-08-09 09:18:27 UTC 
in

Version: 6.4.0.0.alpha0+
Build ID: 63889d3d465e9b4292dd5bb630bd3394494c8a6d
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

it takes

real	0m30,408s
user	0m27,950s
sys	0m0,920s

while in

Version: 6.3.1.0.0+
Build ID: 8b81a453b22611f25674f5e44ae411d78c2fcada
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

it takes

real	0m12,317s
user	0m11,042s
sys	0m0,401s

and in

Version: 6.2.7.0.0+
Build ID: 28c6af3ddc283ca9c5712359a9abcb385c1575b4
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

it takes

real	0m26,985s
user	0m24,227s
sys	0m0,640s

so for me, LibreOffice 6.3.1 is faster. I'll wait for others to comment....
Comment 2 Oliver Brinzing 2019-08-09 13:35:23 UTC 
with: 

Version: 6.3.0.4 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: 

a simple File/Open takes ~15 sec

and converting to pdf ~32 sec (~42 sec if LO is not running):

PS C:\Program Files\LibreOffice 6.3\program> Measure-Command {.\soffice --convert-to pdf --outdir  D:\downloads D:\downloads\table_1034r_13p.odt}                                                                                               

[...]
Seconds           : 32


btw: if i do same with LO 6.2.5.2, soffice.exe will return immediatelly, converting takes ~21 sec:

PS C:\Program Files\LibreOffice 6.2\program> Measure-Command {.\soffice --convert-to pdf --outdir  D:\downloads D:\downloads\table_1034r_13p.odt}                                                                                               

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 7
Comment 3 Paul 2019-08-10 05:56:02 UTC 
(In reply to Oliver Brinzing from comment #2)
> with: 
> 
> Version: 6.3.0.4 (x64)
> Build ID: 057fc023c990d676a43019934386b85b21a9ee99
> CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
> Locale: de-DE (de_DE); UI-Language: en-US
> Calc: 
> 
> a simple File/Open takes ~15 sec
> 
> and converting to pdf ~32 sec (~42 sec if LO is not running):
> 
> PS C:\Program Files\LibreOffice 6.3\program> Measure-Command {.\soffice
> --convert-to pdf --outdir  D:\downloads D:\downloads\table_1034r_13p.odt}   
> 
> 
> [...]
> Seconds           : 32
> 
> 
> btw: if i do same with LO 6.2.5.2, soffice.exe will return immediatelly,
> converting takes ~21 sec:
> 
> PS C:\Program Files\LibreOffice 6.2\program> Measure-Command {.\soffice
> --convert-to pdf --outdir  D:\downloads D:\downloads\table_1034r_13p.odt}   
> 
> 
> Days              : 0
> Hours             : 0
> Minutes           : 0
> Seconds           : 0
> Milliseconds      : 7

Measure-Command can give complete timing if you put the command in a script file, then run the script.  eg Measure-Command {.\test.bat}
Comment 4 Julien Nabet 2019-08-11 09:43:30 UTC 
Created attachment 153290 [details]
perf flamegraph

On pc Debian x86-64 with master sources updated yesterday, I tested this:
./soffice --convert-to pdf table_2178r_26p.odt --headless
and retrieved a Flamegraph
Comment 5 Jean-Baptiste Faure 2019-08-18 20:18:27 UTC 
With LO 6.3.2.0+ under Ubuntu 18.04 x86-64
using the following script:
#!/bin/sh
libreoffice6.3 --convert-to pdf table_1034r_13p.odt --headless

real	0m5.778s
user	0m5.687s
sys	0m0.189s

With LibreOffice 6.2 :

real	0m6,798s
user	0m6,492s
sys	0m0,259s

With LibreOffice 6.1 :

real	0m7,138s
user	0m6,230s
sys	0m0,321s

Note: tests performed while the machine is compiling the master.

Best regards. JBF
Comment 6 Xisco Faulí 2019-09-26 12:02:42 UTC 
Now it takes

real	0m11,578s
user	0m11,481s
sys	0m0,292s


in

Version: 6.4.0.0.alpha0+
Build ID: 186d36a7036462ae641b35004b4ffba3eeeca46f
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

which is 1/3 of my previous measurement in comment 1.

@Paul,
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
Comment 7 Xisco Faulí 2019-09-26 12:03:25 UTC 
real	0m11,231s
user	0m11,090s
sys	0m0,219s

in

Versió: 6.3.1.2
ID de la construcció: 1:6.3.1~rc2-0ubuntu0.18.04.1~lo1
Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; 
Configuració local: es-ES (ca_ES.UTF-8); Llengua de la IU: ca-ES
Calc: threaded
Comment 8 QA Administrators 2020-08-27 03:52:20 UTC Comment hidden (obsolete)
Comment 9 Paul 2020-08-28 15:46:44 UTC 
Hello All.

Apologies, in re-testing this I see some errors in my initial description about setting up the test case.  I can't seem to edit the original description, so this is the corrected version (the url was to the wrong test file):

Test file is : table_2178r_26p.odt
and comes from (bug 84635) : https://bugs.documentfoundation.org/attachment.cgi?id=107266


Test results now (same machine as original - Windows 10, i7):

  6.1.5.2       - 30.5 seconds  (38.2 seconds if %APPDATA%\Roaming\LibreOffice is cleared first)
  6.2.6.1       - 38.9 seconds  (58.2 seconds if %APPDATA%\Roaming\LibreOffice is cleared first)
  6.3.0.4       - 65.5 seconds  (86.2 seconds if %APPDATA%\Roaming\LibreOffice is cleared first)
  6.4.0.0-alpha - 59.8 seconds  (66.2 seconds if %APPDATA%\Roaming\LibreOfficeDev is cleared first)
  6.4.5.2       - 64.9 seconds  (83.5 seconds if %APPDATA%\Roaming\LibreOffice is cleared first)
  6.5.0.0-alpha - 64.5 seconds  (85.0 seconds if %APPDATA%\Roaming\LibreOfficeDev is cleared first)
  6.4.6.2       - 65.0 seconds  (85.2 seconds if %APPDATA%\Roaming\LibreOffice is cleared first)
  7.0.0.3       - 64.7 seconds  (79.6 seconds if %APPDATA%\Roaming\LibreOffice is cleared first)

So, overall since version 6.1.5.2, most versions run this test with performance a little worse than twice as long.

The same commands were used as per the original description:

Windows Powershell> Measure-Command {.\conv.bat}

where conv.bat converts using a specific install of Libre Office:

  "\Program Files\LibreOffice6.1.5.2\program\soffice.exe" --convert-to pdf table_2178r_26p.odt --headless
Comment 10 Luboš Luňák 2021-03-26 21:58:27 UTC 
This was noticeably improved by my recent font caching changes.