I remember reading many years ago that changing the undo and graphics cache settings under Tools > Options > LibreOffice > Memory would improve the performance and recently a user who was experiencing sluggish performance with calc ( http://www.ghacks.net/2015/08/05/libreoffice-5-0-is-available/#comment-3627714 ) solved this problem by changing the graphics cache settings. So i'm wondering whether we should change these defaults to something more useful so that users dont have to change them, also we did remove the limit of the graphics cache to 256MB in LO 4.4. Graphics Cache Use for LibreOffice : 20 MB Memory per object : 5.2 MB Remove from memory : 10 Min Different webpages recommendation of changing the value :- 128 MB & 20 MB - https://wiki.archlinux.org/index.php/LibreOffice#Speed_up_LibreOffice 100 MB - https://ask.libreoffice.org/en/question/93/images-slow-down-performace/
Hi Jay, I agree (and would swear there is an issue for this, but where..) Cheers Cor
Link 1. is a primary exhibit in the "Clueless Ricer" category. The Graphics Cache size has -zero- impact on startup performance whatsoever. What does help is a second-start ;-) so this is just measuring the page-cache win. Having said that link #2 is more sane; I think increasing the graphics cache to 128Mb and 24Mb or something may make some sense. It'd be nice to have some -real- quantitative data however; and that's hard to get - since we don't really have performance measuring for lots of image heavy tasks. Tor - please can you can create a patch of this kind (should be a quick officecfg/ hack) and push it into our benchmarking harness ?
IIRC Tamas was looking at the graphic cache size some time ago? Is the graphic cache size actually the same as what you set in the configuration or is there some multiplier applied?
Should we also be looking into increasing 'Cache for Inserted Objects' from its current value of 20 as i'd assume that is graphics cache related?
(In reply to Michael Stahl from comment #3) > IIRC Tamas was looking at the graphic cache size some time ago? > > Is the graphic cache size actually the same as what you set in the > configuration or is there some multiplier applied? I removed the multiplier last time, so I guess it's the same value. Except that the old caching mechanism (GraphicCache class) still called in parallel with the newer caching mechanism (GraphicObject class). So the real memory usage can be twice of the configured value.
Hi, added to this report data that I had commented in https://bugs.documentfoundation.org/show_bug.cgi?id=96095 Test with the file https://wiki.documentfoundation.org/images/0/0f/GS42-GettingStartedLO.odt reported by @Jay in 96095. Win10x64 Version: 5.0.4.0.0+ Build ID: 65bdad52a04dc1f5d771bdfdc8bce23e9ba74296 TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-0, Time: 2015-11-26_16:11:50 After clean profile, takes about 01'35" before CPU goes to zero. With graphics cache: 32 Mb takes about 01'34" before CPU goes to zero. With graphics cache: 48 Mb takes about 01'14" before CPU goes to zero. Version: 5.2.0.0.alpha0+ Build ID: dc269d07e8e5d71818bc0a546c3daef4d50eb1c7 Threads 4; Ver: Windows 6.19; Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2015-11-27_07:36:59 After clean profile, takes about 03'55" before CPU goes to zero. With graphics cache: 32 Mb takes about 03'55" before CPU goes to zero. With graphics cache: 48 Mb takes about 01'00" before CPU goes to zero. Seeing the big difference on times until the CPU load is reduced, the low. is a 20% less time for 5.0.4, The change at least of the default memory size for graphics cache, seem fine, taking in account that 48 Mb I think is a low value and acceptable for basic computers.
Someone stopped by the design IRC today asking about why LO took a long time to load a document and i suggested he submit the document in a bug report and then he returned later to say that the problem was solved by visiting the below link, which suggested the same as the arch link of 128mb and 20mb. https://www.organicweb.com.au/17237/general-technology/libre-office-slow/ (In reply to m.a.riosv from comment #6) > Hi, added to this report data that I had commented in > https://bugs.documentfoundation.org/show_bug.cgi?id=96095 > > Test with the file > https://wiki.documentfoundation.org/images/0/0f/GS42-GettingStartedLO.odt > reported by @Jay in 96095. Thanks for the tests. Would be great if you did some with larger values like 64, 128, 256 and possible mix in changing Memory per object to 10, 15, and 20. How can we move this forward as this seems like it should be an easy fix?
I had reported those numbers because change the memory it's in my test the only relevant for speed up the load, and only until 48 Mb. New test. Win10x64 Version: 5.1.2.0.0+ (x64) Build ID: 6b3dd63dea6861180f438db71ca3f73df2aef200 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-1, Time: 2016-03-06_03:42:47 After clean profile, 20 Mb 1 pObj takes about 00'43" before CPU goes to zero. With graphics cache: 32 Mb 1 pObj takes about 00'42" before CPU goes to zero. With graphics cache: 48 Mb 1 pObj takes about 00'16" before CPU goes to zero. With graphics cache: 128 Mb 1 pObj takes about 00'16" before CPU goes to zero. With graphics cache: 48 Mb 10 pObj takes about 00'16" before CPU goes to zero. With graphics cache: 128 Mb 10 pObj takes about 00'16" before CPU goes to zero. It's clear that's a great improvement for a little change, as I commented seems very admissible even for very basic computers. What I don't know is if some non visible could help even more, e.g. taken advantage of change the object's number.
(In reply to m.a.riosv from comment #8) > I had reported those numbers because change the memory it's in my test the > only relevant for speed up the load, and only until 48 Mb. Thanks. As one the core functionality of libreoffice is to load files, improving the speed of the loading would IMO be the most important fix we could do, just like we improved the speed of launching in 5.0. I attempted to make a patch but the code was to difficult for my non-C++ skills, so here is a code pointer for whomever wants to take this on. I would assume it should be easy to fix. http://opengrok.libreoffice.org/xref/core/cui/source/options/optmemory.cxx
Reading again the comments, and following comment#5 I have analyzed from 39 to 48 and just 48 makes the difference for me. @Jay I guess a comment in the ESC could activate this change.
Submitted a patch to gerrit on this issue, https://gerrit.libreoffice.org/#/c/22967/ Suggestion of modified values were given by Yousuf Philips. To be conservative, We went with half of what Michael Meeks suggested. Things can be tested and tweaked accordingly. Thanks.
(In reply to Akshay Deep from comment #11) > Submitted a patch to gerrit on this issue, > https://gerrit.libreoffice.org/#/c/22967/ > > Suggestion of modified values were given by Yousuf Philips. To be > conservative, We went with half of what Michael Meeks suggested. Thanks! For clarity, the patch sets object cache size to 12 MB and total cache size to 64 MB?
(In reply to Cor Nouws from comment #12) > For clarity, the patch sets object cache size to 12 MB and total cache size > to 64 MB? Yes. :D
Thanks for the patch; merged to master. Still not that convinced it will help significantly ;-) certainly for startup - but for some document load/layout it may.
Akshay Deep committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=75c272c146045235783e1dfe26a162a8f4dee493 tdf#94760 Better default values for graphics cache It will be available in 5.2.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.