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
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
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.
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)
Created attachment 136754 [details] Bibisect log ~/bibisect-win32-6.0 $ git bisect good 0354bd81150a88923212fdbad777803c0ce51590 is the first bad commit commit 0354bd81150a88923212fdbad777803c0ce51590 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Jul 29 17:05:17 2017 -0700 source 600a2aa24085cb972686b46061f9045785208a9e source 600a2aa24085cb972686b46061f9045785208a9e :040000 040000 86b6901e1959c52103b17e4f6b0cdc35bcf02f34 adf404ff7115ae0d50a019d29e873fc70aafea4a M instdir --- author Armin Le Grand <Armin.Le.Grand@cib.de> 2017-06-12 17:31:10 (GMT) committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-07-15 09:01:29 (GMT) commit 600a2aa24085cb972686b46061f9045785208a9e (patch) tree 33b323e9b28064d7faca98381d29a94324d78fa5 parent 5868745db74ae930edb0058490076d82aaeafbe9 (diff) emfplus: for convenience added fallback For development and to not be dependent of the progress of the coming EMF+ importer, for now add fallback to using the old Metafile importer, plus conversion to primitive representation. That way the whole encapsulation is ready and can already be used Change-Id: I29afadaaaba71d75d0f5593852f4cc0cb3dd13f8
Adding Cc to Armin Le Grand
The change 600a2aa24085cb972686b46061f9045785208a9e was only in place temporarily, so it can not be the reason
Comment on attachment 136754 [details] Bibisect log >~/bibisect-win32-6.0 >$ git bisect log ># bad: [ddecdea9405d0b2655f54bbcb918975c5d8a9495] source 9127d1a89cbfba89eb9df6755ea7b9e161cfc67a ># good: [cc5c4c7ed1d8d01b0063bcaaeb5f6d59282c8029] source 9feb7f7039a3b59974cbf266922177e961a52dd1 >git bisect start 'origin/master' 'oldest' ># bad: [748d85d903dc0f87d6ad9df24f77b753eab28e74] source 65c69af584152a5f8f3d2f9752d9f051660b7755 >git bisect bad 748d85d903dc0f87d6ad9df24f77b753eab28e74 ># good: [246e8d948404996dbd37fcaa2a4bc785a45184ec] source 3b0f8ece47f70f53b1462c824463c453b47c3020 >git bisect good 246e8d948404996dbd37fcaa2a4bc785a45184ec ># good: [5b18d05b0ce4dd174ec271cf4816426dcd2b739a] source 9a5769dd1b30b7aa369affa93e38bfffe972a300 >git bisect good 5b18d05b0ce4dd174ec271cf4816426dcd2b739a ># good: [8cbe335d85c351e280a45e0febb1fb98a5ee2016] source 00aa0892e7385cd8395dd39814077958be42e720 >git bisect good 8cbe335d85c351e280a45e0febb1fb98a5ee2016 ># bad: [92c95d4d45415ba5d3eef825cee24fbe960b000f] source 7243c13bdd4cbc528673b658faea6772077fa1f6 >git bisect bad 92c95d4d45415ba5d3eef825cee24fbe960b000f ># good: [9c302a6c638c37f08dd9a17232e358e74af86b05] source cc438f60d6ad0855f754dd32da9c9a80c7cabf92 >git bisect good 9c302a6c638c37f08dd9a17232e358e74af86b05 ># bad: [bc891014cf5dec94be248cfc87f91cf6b1778114] source d62d7803adb65c6c6469bf0709dc862d3b06c4a4 >git bisect bad bc891014cf5dec94be248cfc87f91cf6b1778114 ># bad: [3231eea9d0e51fdb5056264539bc3913370a842a] source 522d211764725b19b7975f500f315444601cdf6b >git bisect bad 3231eea9d0e51fdb5056264539bc3913370a842a ># bad: [14209bf9b53ac7c1f30b33bb3d389b0295639505] source b128f8f0bcd5f5378c559c8fdd506cfb51ff09b3 >git bisect bad 14209bf9b53ac7c1f30b33bb3d389b0295639505 ># bad: [0354bd81150a88923212fdbad777803c0ce51590] source 600a2aa24085cb972686b46061f9045785208a9e >git bisect bad 0354bd81150a88923212fdbad777803c0ce51590 ># good: [2c6c599f7d8b57a81aee0999aab3031b3069148a] source 79f5cb620984c4d04d53a497e698472b2192d2bb >git bisect good 2c6c599f7d8b57a81aee0999aab3031b3069148a ># good: [538fdba25a0ebda3f4b333de6e850569b04081a6] source 5868745db74ae930edb0058490076d82aaeafbe9 >git bisect good 538fdba25a0ebda3f4b333de6e850569b04081a6 ># first bad commit: [0354bd81150a88923212fdbad777803c0ce51590] source 600a2aa24085cb972686b46061f9045785208a9e
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
Patch in gerrit: https://gerrit.libreoffice.org/#/c/45704/
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.
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.
I guess Bartosz' fix is an improvement, but bug is not solved.
(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 ?
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
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
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.
(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
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.
(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.