Download it now!
Bug 94760 - Better default values for graphics cache
Summary: Better default values for graphics cache
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha0+ Master
Hardware: Other All
: high major
Assignee: Akshay Deep
URL:
Whiteboard: target:5.2.0
Keywords: needsDevEval, topicUI
Depends on:
Blocks:
 
Reported: 2015-10-04 19:11 UTC by Yousuf Philips (jay) (retired)
Modified: 2016-10-25 19:08 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-10-04 19:11:05 UTC
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/
Comment 1 Cor Nouws 2015-10-04 21:09:19 UTC
Hi Jay,

I agree (and would swear there is an issue for this, but where..)
Cheers Cor
Comment 2 Michael Meeks 2015-10-05 08:27:33 UTC
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 ?
Comment 3 Michael Stahl (CIB) 2015-10-05 08:50:00 UTC
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?
Comment 4 Yousuf Philips (jay) (retired) 2015-10-05 09:48:05 UTC
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?
Comment 5 Tamás Zolnai 2015-10-05 19:44:18 UTC
(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.
Comment 6 m.a.riosv 2015-11-27 23:13:45 UTC
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.
Comment 7 Yousuf Philips (jay) (retired) 2016-03-05 21:34:33 UTC
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?
Comment 8 m.a.riosv 2016-03-06 15:05:47 UTC
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.
Comment 9 Yousuf Philips (jay) (retired) 2016-03-06 21:50:27 UTC
(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
Comment 10 m.a.riosv 2016-03-07 01:56:57 UTC
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.
Comment 11 Akshay Deep 2016-03-07 05:10:17 UTC
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.
Comment 12 Cor Nouws 2016-03-07 10:03:44 UTC
(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?
Comment 13 Yousuf Philips (jay) (retired) 2016-03-07 11:00:34 UTC
(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
Comment 14 Michael Meeks 2016-03-23 17:30:04 UTC
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.
Comment 15 Commit Notification 2016-03-23 17:31:46 UTC
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.