[Gllug] Re: Memory usage

[Peter Grandi]

>>> On Thu, 13 Oct 2005 01:33:43 +0100, Tethys
>>> <sta296 at astradyne.co.uk> said:

[ ... ]

>> Well, OOo is a lot less bloatware than some complain about
>> (here OOo 1.1.5 starts in 10-12 seconds from cold and 2-3
>> seconds if it is already a bit cached, and this is a pretty
>> low end PC).

sta296> *How*? My PC is anything but slow:

sta296> [ ... 2x3GHz CPU with 1GiB of memory ... ]

My PC has one 1.6GHz Athlon XP and in particular ''just'' 512MiB
of memory, thus my constant struggles with memory and swapping.

Some tuning notices, just in case (they are unlikely to have a
major effect):

* As to the CPUs, if you have a single CPU with HT, then unless
  you have a very recent kernel, then I ahve read that it is
  probably better to disable it as the scheduler does not handle
  that very well (sticky thread/process affinity is required for
  good performance).

* As to the 1GiB of memory I notice that you have 905900 'total',
  when by default because of kernel mappings it should be a
  little bit less (896KiB - kernel size) than that.

  There are two possibilities here: you or your distribution have
  enabled the 1GiB high memory, which slows things down a bit, or
  enabled the tradeoff between user and kernel address space.
  If you have high mem enabled, 'grep HighTotal /proc/meminfo'
  will not be zero.

  Not having high mem is preferable (not by much), and instead
  of of the (3GiB user+1GiB kernel) default, you might want to
  switch to the (2.5GiB user + 1.5GiB kernel) setting or even
  the (2GiB user + 2GiB kernel) one. Unless one really needs
  the 3GiB user address space size instead of the 2GiB one.

sta296> Yet for me OO.o writer takes 22 seconds from cold, or 13
sta296> seconds if cached. [ ... ] I can only assume that you're
sta296> running a desktop environment that already uses

I actually use almost only KDE nowadays. In any case, I just did
a bit of looking at the (static) dependencies of 'soffice.bin'
and the various '.so's in the OOo 'program' directory, and it
look like that OOo tends to use its own copy of many libraries
(including the GCC runtime ones) with a few exceptions. It looks
pretty self contained, and not very much into sharing.

sta296> some of the same shared libraries as OO.o. [ ... ]

So this is not likely to be a factor.

Perhaps I may have been a bit more careful with FontConfig/Xft2
fonts (one of my pet peeves), IIRC recent versions of OOo have
switched to it almost completely, previously it used its own
font system.

However as to your specific setup I notice two things:

* You are using 1.9.125, which is a beta version. Sometimes beta
  versions are compiled in debug mode, which does mean larger
  code and slowness. Or perhaps simply the 2.0 series has become
  bigger than the 1.1 series, but a quick look tells me that
  this is not much the case.

* Your memory report shows that half of your 1GiB is for the
  page cache. For various reasons this is not very useful:
    http://WWW.sabi.co.UK/Notes/anno05-4th.html#051008
  So I would suggest reducing the 'vm/swappiness' parameter
  significantly, to something like 10 or 20.

But guessing wildly the difference is most likely due to
scattered on-disc layout; I have recently reloaded my 'root'
partition, thus ensuring more clustering:

  http://WWW.sabi.co.UK/Notes/anno05-4th.html#051010

and a 'tar' of the partition became seven times faster, and
interactive usage feel rather snappier.

Now starting an application that consists of many files (main
executable, libraries, fonts, ...) is roughly equivalent to
'tar'ing it up, and if all the bits and pieces are scattered on
disc, bad news.

To check this do the following: type "time soffice" and then as
soon as the window appears type "CTRL-Q" to terminate it as soon
as it is ready. What I get from cold and from warm is:

----------------------------------------------------------------
  $  time soffice

  real    0m10.500s
  user    0m2.420s
  sys     0m0.340s
  $  time soffice

  real    0m3.424s
  user    0m2.600s
  sys     0m0.200s
----------------------------------------------------------------

Note: this starts up with an empty window. Starting up with an
empty writer page takes a 1-2 seconds longer.

The notable thing is that when the OOo is cached (second
invocation) it is mostly CPU time.

It is hard to believe that your OOo when starting from cache
takes a large fraction of 13 seconds of CPU time on a CPU
probably twice as fast as mine. So perhaps it is either a
debug-flags build, or it is still groping for way too many
files, but then they should be cached...

However, if you have a spare partition you can reformat it may
be useful to re-make its filesystem, install to it OOo 1.1.5
from scratch (let's say from the downloadable installer to make
sure), and check that how long it takes to start from there.
By unmounting that partition you can flush the cached blocks,
and thus ensure a cold start.

Also, check the FontConfig/Xft2 font list with

  fc-list | sort -df | less -S

as it might also be useful to see if it can be trimmed,
especially of asian fonts.

[ ... ]

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug