Re: Memory options defaults

On Fri, 2012-07-20 at 22:35 -0300, Olivier Hallot wrote:
> Someone from the Brazilian users list raised an issue about the current
> memory defaults we carry in our age-old options. He argues that the
> current values were set when computers were short on GBytes, which is
> not the case anymore actually.

        Heh ;-)

> He also claims that there are better figures to put that improves LO
> performance, and those figures should be a function of the amount of RAM
> available.

        There is an urban myth that those figures improve startup performance
based on horribly inaccurate profiling of cold vs. warm start. Of
course, it is possible that increasing these numbers may help in some
cases.

        Having said that - the graphics caching is itself -utterly -utterly-
broken and the image lifecycle is busted beyond belief as is visible in
numerous comments through the code and a tracker bug here:

        https://bugs.freedesktop.org/show_bug.cgi?id=47148

        Tracks that I guess; we need to fix it - images should be immutable and
managed with a hard lifecycle mechanism such as a reference count that
cannot be screwed up; the current attempt at a unique / hashed string /
path and manual lifecycle management is broken. Images' source should
not be documents that go away and/or are over-written, autosave should
not impact your likelihood of loosing images etc. etc. ;-)

        As it is, when we save / load (IIRC) writer forces images out of the
cache anyway and then brings them back in; so basically the whole thing
is busted - and these tweak-ables are pretty horrific too ;-)

> Does it worth to review our memory figures?

        Come up with a patch & get it reviewed I guess. I imagine you have a
good feel for how much is useful. Be aware that if we wander into using
swap for our 'cache' we will quite possibly make everything way slower
than having no cache ;-)

        Ideally - we'd find time to fix the whole image story - sadly that
means passing some new XFoo through innumerable UNO interfaces instead
of string image names which is one factor making it harder to re-factor.

        ATB,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot