Re: [Tracker] trackerd memory efficiency

[Philip Van Hoof <spam pvanhoof be>]

On Fri, 2009-01-23 at 14:41 +0200, Tshepang Lekhonkhobe wrote:
> On Fri, Jan 23, 2009 at 2:36 PM, Carlos Garnacho <carlos imendio com> wrote:
> > On vie, 2009-01-23 at 14:08 +0200, Tshepang Lekhonkhobe wrote:
> > > Hi,
> > >
> > > README champions the daemon as memory efficient (3-30MB RAM) and I'd
> > > like to send a patch that removes the whole paragraph since that's no
> > > longer the case.
> >
> > Could you back up such statement with valgrind logs? If that's truly not
> > the case, patches to make that paragraph true would be more appreciated,
> > really
>
> No, but am just looking at top that tells me more of 35MB currently.

Note that top usually reports VmSize. VmSize is all of the memory being
used by the process. This is of course an irrelevant figure as that
includes the shared memory too (memory shared with other processes, like
libraries being mapped into memory already).

What you want to look at it usually VmRss. That's a far more interesting
number to know.

You can get the VmRss from the kernel by reading the /proc entries.

Valgrind will only report what malloc() & co have allocated. Also that
ain't a correct number as a kernel wont always immediately allocate the
entire requested size. Instead it creates pages as the memory that was
requested is being written to.

So if you do malloc(10M), then you won't be using 10M until you start
writing to all of the bytes of the 10M.

The extractor of tracker will for example request a rather large
allocation this way, but we assume the kernel to only really alloc as
pages are requested (to avoid having to excessively do realloc instead).

So just looking at top is definitely not a good way to measure.

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be