Bug 109340 - Impress: The memory usage on slide scroll increased in 6.0 with a factor 3 @900 MB (compared to 5.4 @300 MB) for small PPT (1,2 MB) with equation objects that's slow to load
Summary: Impress: The memory usage on slide scroll increased in 6.0 with a factor 3 @9...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.0.1
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: EMFPlus-Rework-Regressions
  Show dependency treegraph
 
Reported: 2017-07-25 15:39 UTC by Telesto
Modified: 2018-11-27 15:59 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Allocations (321.98 KB, application/x-zip-compressed)
2017-09-08 09:55 UTC, Telesto
Details
Bibisect log (2.28 KB, text/plain)
2017-10-04 10:17 UTC, Telesto
Details
Bibisect log (2.78 KB, text/plain)
2017-10-18 09:29 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-07-25 15:39:26 UTC
Description:
The memory usage for slide sorter has increased with a factor 3 (compared to 5.4.0.2)

Steps to Reproduce:
1. Open http://www.cs.rpi.edu/~moorthy/Courses/S04/modcomp/class14.ppt
2. View -> Slide Sorter
3. Scroll down until all previews are loaded. Monitor the memory usage
850 MB of ram is needed rendering them. With 5.4.0.2 is only 237 mb
4. Save the file as ODP -> Memory usage will immediately drop to 161 mb

Actual Results:  
Memory usage increases a lot

Expected Results:
Similar behavior as before


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: 6.0.0.0.alpha0+
Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-21_02:58:26
Locale: nl-NL (nl_NL); Calc: CL

but not in
Version: 5.4.0.2
Build ID: 2b906d450a44f2bbe506dcd22c51b3fa11dc65fd
CPU threads: 4; OS: Windows 6.2; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Xavier Van Wijmeersch 2017-07-26 11:54:13 UTC
I cannot reproduce with

Version: 5.4.1.0.0+
Build ID: 6622ea7365fbf1b425e5f90667dd7e6466fd0293
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2017-07-21_06:37:51
Locale: nl-BE (en_US.UTF-8); Calc: group

but with 

Version: 6.0.0.0.alpha0+
Build ID: 930e92f45ac3b712702baae1c34bbb746726303c
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

i have about 750mb increase of memory and slow to load the file
Comment 2 Timur 2017-07-26 15:52:04 UTC
It's not about Slide sorter, also in Normal, just scroll slowly thorough all slides. 
This bug is reproducible. Question is: what is it related to? 
There are a lot of meta bugs, some of them useless in my view, but bugs like this one are the most important to be connected to similar ones. 
Telesto, please try to find related bugs and track this one for a change. I'm not sure it will be resolved. Also not sure whether bibisect is possible or valgrind would be more useful.
Comment 3 Telesto 2017-09-08 09:55:46 UTC
Created attachment 136117 [details]
Allocations

Not sure if it's useful (or reading it correctly), but the 'leaking' seems to be related to std::__1::shared_ptr<unsigned char> o3tl::make_shared_array<unsigned char>(unsigned long)
Comment 4 Telesto 2017-10-04 10:17:01 UTC Comment hidden (obsolete)
Comment 5 Telesto 2017-10-04 10:19:06 UTC
Adding Cc to Armin Le Grand
Comment 6 Armin Le Grand 2017-10-18 07:27:21 UTC
The change 600a2aa24085cb972686b46061f9045785208a9e was only in place temporarily, so it can not be the reason
Comment 7 Telesto 2017-10-18 09:27:44 UTC Comment hidden (obsolete)
Comment 8 Telesto 2017-10-18 09:29:00 UTC
Created attachment 137072 [details]
Bibisect log

Second attempt:

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2017-06-12 17:54:12 (GMT)
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2017-07-15 09:01:29 (GMT)
commit	b93d0cadb79f6652dec4d29ef20813f1d57cc708 (patch)
tree	f1b2d1ddaeb81c8d777dbf86c2b731e33b80085a
parent	600a2aa24085cb972686b46061f9045785208a9e (diff)
emfplus: use size of image of metafile fallback
Comment 9 Xisco Faulí 2017-12-06 09:48:20 UTC
Patch in gerrit: https://gerrit.libreoffice.org/#/c/45704/
Comment 10 Commit Notification 2017-12-06 13:25:56 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b0f064dc4e7d33fe9bd927dae35ab0a4ef97b5f

tdf#109340 Improve performance by reducing matrix multiplication

It will be available in 6.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2017-12-08 12:01:17 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f609433730ecdbc23096b9362df596a0b703d37&h=libreoffice-6-0

tdf#109340 Improve performance by reducing matrix multiplication

It will be available in 6.0.0.1.

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

Affected users are encouraged to test the fix and report feedback.
Comment 12 Timur 2017-12-08 13:40:13 UTC
I guess Bartosz' fix is an improvement, but bug is not solved.
Comment 13 Xisco Faulí 2018-01-08 10:34:57 UTC
(In reply to Timur from comment #12)
> I guess Bartosz' fix is an improvement, but bug is not solved.

@Telesto,
Could you please check which is the memory usage in master ?
Comment 14 Telesto 2018-01-12 21:48:04 UTC
Repro with:
Version: 6.1.0.0.alpha0+
Build ID: ef22c4a0a99be5d2903fb9e9d09fc852cd791173
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-01-12_09:16:04
Locale: nl-NL (nl_NL); Calc: CL

Noticing a slight decrease: 825MB instead of 900MB
Comment 15 Telesto 2018-03-15 13:27:05 UTC
Repro with:
Version: 6.1.0.0.alpha0+
Build ID: e5bc7fa4e83b33fc3eee343e560a4f8cb91eacd6
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-14_23:37:38
Locale: nl-NL (nl_NL); Calc: CL
Comment 16 Timur 2018-08-01 14:16:24 UTC
Looks like memory issue is gone in 6.2+, it's only 240 MB for me. 
Question remains why is fileopen and scroll so slow.
Comment 17 Buovjaga 2018-11-25 08:51:44 UTC
(In reply to Timur from comment #16)
> Looks like memory issue is gone in 6.2+, it's only 240 MB for me. 
> Question remains why is fileopen and scroll so slow.

How slow is slow? Time from start center is 7 seconds for me. Scrolling is fast in slide sorter or normal preview pane.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 51e6a95757906dff8b2819a4141bf3dc7938e95f
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 24 November 2018
Comment 18 Timur 2018-11-27 10:59:18 UTC
The bug started as memory issue, and that's not reproducible anymore in Windows (memory usage 150 MB in 6.3+ 64-bit and 90 MB in 6.3 32-bit).
Scrolling is also fast. 
Let's close the bug. 

First fileopen time for me in Windows:
75 seconds LO 6.3+, tested both with x86 and x64. 
100 seconds with LO 5.4. 
60 seconds with LO 5.2. 
40 seconds with LO 4.0.
15 seconds with OO.
MSO takes 8 seconds. 
So it is slow in current master (note: without dump) but another issue.
Comment 19 Buovjaga 2018-11-27 15:59:52 UTC
(In reply to Timur from comment #18)
> The bug started as memory issue, and that's not reproducible anymore in
> Windows (memory usage 150 MB in 6.3+ 64-bit and 90 MB in 6.3 32-bit).
> Scrolling is also fast. 
> Let's close the bug. 
> 
> First fileopen time for me in Windows:
> 75 seconds LO 6.3+, tested both with x86 and x64. 
> 100 seconds with LO 5.4. 
> 60 seconds with LO 5.2. 
> 40 seconds with LO 4.0.
> 15 seconds with OO.
> MSO takes 8 seconds. 
> So it is slow in current master (note: without dump) but another issue.

I tested on Windows 10: 3.3.0 takes 23 secs, 6.2 beta1 takes 26 secs.