Bug 140639 - It is not possible to work with an older document from LO 6.4 in new LO 7.0, slow perf
Summary: It is not possible to work with an older document from LO 6.4 in new LO 7.0, ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0 target:7.1.3 target:7.0.6
Keywords: bibisected, perf, regression
Depends on:
Blocks:
 
Reported: 2021-02-24 11:21 UTC by Karsten
Modified: 2021-04-16 09:40 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Document that is very slow in Libreoffice 7 (365.29 KB, application/vnd.oasis.opendocument.graphics)
2021-02-24 11:22 UTC, Karsten
Details
Preview as PDF generated in Version 6.4.6.2 (90.81 KB, application/pdf)
2021-02-24 11:23 UTC, Karsten
Details
strip original document down to problematic svg (163.95 KB, image/svg+xml)
2021-04-14 10:48 UTC, Caolán McNamara
Details
this modified svg functions fine (153.82 KB, image/svg+xml)
2021-04-14 10:49 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karsten 2021-02-24 11:21:17 UTC
Description:
I am using Libreoffice Draw to create nice documents.
Up to Libreoffice 6.4.6.2 this works a little bit slow but it works.

Now with Libreoffice 7.0.4.2 it is impossible to do this, because it is so slow that Libreoffice is not reacting.


Version: 7.0.4.2
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kf5
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Steps to Reproduce:
Open the attached document and try to work with it.

Actual Results:
It is not possible because Libreoffice reacts to slow.

Expected Results:
Libreoffice should work as fast as in version 6.4.6.2 or better.


Reproducible: Always


User Profile Reset: No



Additional Info:
Please keep in mind that new features are not so important then general functionality.
Thank you for your work and understanding.
Comment 1 Karsten 2021-02-24 11:22:10 UTC
Created attachment 170022 [details]
Document that is very slow in Libreoffice 7
Comment 2 Karsten 2021-02-24 11:23:06 UTC
Created attachment 170023 [details]
Preview as PDF generated in Version 6.4.6.2
Comment 3 Roman Kuznetsov 2021-02-24 12:16:07 UTC
Confirm a perf problem in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 62dff2844b0bf1d1bcb8eb4d6db529ef4a31bee4
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded

and in

Версия: 6.4.5.2 (x86)
ID сборки: a726b36747cf2001e06b58ad5db1aa3a9a1872d6
Потоков ЦП: 4; ОС: Windows 10.0 Build 18363; Отрисовка ИП: по умолчанию; VCL: win; 
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded

and in

Version: 6.3.3.2 (x86)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

too. 

I'm not sure it's a regression in this case, but possibly there is a difference between Windows and Linux there
Comment 4 Karsten 2021-02-24 12:39:28 UTC
Is there an easy way to run the actual development version in an container?
The last version to download seems to be 7.1.1

Older versions are not interesting, because the problem did not occur in the versions before.

Maybe there is a general performance problem, so have a look at https://bugs.documentfoundation.org/show_bug.cgi?id=140635 ?
Comment 5 Timur 2021-02-24 17:40:30 UTC Comment hidden (obsolete)
Comment 6 Karsten 2021-02-25 09:56:47 UTC
(In reply to Timur from comment #5)
> Which container? There's https://libreoffice.soluzioniopen.com/daily-version/

Thanks - that's good for testing.

With LibreOfficeDev-7.2.0.0.alpha0_2021-02-15-x86_64.AppImage i have the same results.
Libreoffice seems sometimes to lock the complete KDE for many seconds.
In the process list i can see that soffice.bin is blocking with 100% cpu load.
Comment 7 Karsten 2021-03-09 14:54:35 UTC
I deinstalled LibreOffice 7, because other annoying bugs appeared.

Now i installed

Version: 6.4.7.2
Build-ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
CPU-Threads: 4; BS: Linux 4.19; UI-Render: Standard; VCL: kf5; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded

and here it is no problem to work with the attached Libreoffice Draw document.
So some changes has been made in LibreOffice 7 that are causing inherent performance problems.
Comment 8 Timur 2021-04-13 10:19:14 UTC
I confirm that perf regression started from 7.0, similar in 7.2+, test with timeout command, seen big cpu and time. 
Tested in Linux Mint Gtk3.
Comment 10 Caolán McNamara 2021-04-14 10:48:53 UTC
Created attachment 171186 [details]
strip original document down to problematic svg

can be reproduced with just blank draw and insert this image
Comment 11 Caolán McNamara 2021-04-14 10:49:48 UTC
Created attachment 171187 [details]
this modified svg functions fine

here the text paths causing the problem is removed and it functions well
Comment 12 Commit Notification 2021-04-14 12:38:06 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3a933fddfdbbe158caac47b9957fb3c8d92506fb

tdf#140639 cache FcPattern for font options

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Karsten 2021-04-14 12:44:51 UTC
(In reply to Caolán McNamara from comment #11)
> Created attachment 171187 [details]
> this modified svg functions fine
> 
> here the text paths causing the problem is removed and it functions well

So it is not allowed to use the full functionality of SVG ?

Besides - the text path is not rendered with the correct True-Type-Font.
Comment 14 Xisco Faulí 2021-04-15 13:19:01 UTC
Verified in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: a199e4ea389c934d169a178433f4b94033e60f93
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Caolán, thanks for fixing this issue!!
Comment 15 Commit Notification 2021-04-15 13:20:26 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/365df37004630b68afafdc676e26f2599c2194a9

tdf#140639 cache FcPattern for font options

It will be available in 7.1.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Timur 2021-04-15 14:04:50 UTC Comment hidden (obsolete)
Comment 17 Caolán McNamara 2021-04-15 16:31:05 UTC
I think the committed https://gerrit.libreoffice.org/c/core/+/114140 is the fundamental problem bringing the doc from never renders to renders in useful time.

The additional https://gerrit.libreoffice.org/c/core/+/114173 and https://gerrit.libreoffice.org/c/core/+/114172 (gen only) appear in profiling as minor contributions too.

Turning vcl/source/font/fontcache.cxx from its current 50 to 500 would have an additional improvement for scrolling, but at a cachesize cost. The text path for the red text around the margin is done by RenderTextSimpleOrDecoratedPortionPrimitive2D by creating ~500 slightly different fonts each with a different orientation.
Comment 18 Karsten 2021-04-16 07:40:21 UTC Comment hidden (obsolete)
Comment 19 Xisco Faulí 2021-04-16 07:45:29 UTC Comment hidden (obsolete)
Comment 20 Xisco Faulí 2021-04-16 07:46:04 UTC
(In reply to Xisco Faulí from comment #19)
> (In reply to Karsten from comment #18)
> > (In reply to Timur from comment #16)
> > > Karsten, please test with daily master from link in fix, I guess it will be
> > > ready tomorrow. 
> > > I'm waiting for bibisect repo to be updated.
> > 
> > How it can be tested?
> > 
> > Is there something like an appimage?
> > 
> > Here https://libreoffice.soluzioniopen.com/daily-version/ the last version
> > is from 12. April.
> > 
> > An how can the fontcache vcl/source/font/fontcache.cxx be tuned from 50 to
> > 500 ?
> 
> Just download a recent daily build ( newer than 2021-04-14 12:38:06 UTC )
> from https://dev-builds.libreoffice.org/daily/master/

* https://dev-builds.libreoffice.org/daily/master/current.html
Comment 21 Commit Notification 2021-04-16 09:32:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/ceb556971b163a98e7a46ea573717fe8813047f4

tdf#140639 cache FcPattern for font options

It will be available in 7.0.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Timur 2021-04-16 09:40:48 UTC
When I wrote test with daily master from link in fix, it's because it's updated more often. Appimage is easy, but appears after some days. 

Anyway, looks as fast as it was from user perspective.