Re: [Tracker] trackerd memory efficiency

[Tshepang Lekhonkhobe <tshepang gmail com>]

On Thu, Feb 5, 2009 at 12:14 PM, Carlos Garnacho <carlos imendio com> wrote:
> On jue, 2009-02-05 at 11:24 +0200, Tshepang Lekhonkhobe wrote:
> > 2009/2/5 Martyn Russell <martyn imendio com>:
> > > Tshepang Lekhonkhobe wrote:
> > > > > What I meant was the RES column in top, just to be clear.
> > > > >
> > > > > I anyways ran $ valgrind --leak-check=full --show-reachable=yes
> > > > > --leak-resolution=high -v /usr/libexec/trackerd
> > > > >
> > > > > and go the following output, and I don't know what it says:
> > > > >
> > > > > ==6792== LEAK SUMMARY:
> > > > > ==6792==    definitely lost: 36 bytes in 1 blocks.
>
> These are the bytes that valgrind consider leaked for sure
>
> > > > > ==6792==    indirectly lost: 120 bytes in 10 blocks.
>
> And this is not freed memory pointed by freed/leaked pointers.
>
> Actually, these 2 "leaks" aren't such, since it's the XDG directories
> cache in glib.
>
> > > > > ==6792==      possibly lost: 43,872 bytes in 84 blocks.
>
> Valgrind couldn't guess whether 43Kb were leaked or not, it could be
> interesting knowing where does that come from, but it's probably all
> these operations with pointers in parsing/stemming, and inside
> sqlite/qdbm which are confusing valgrind.
>
> > > > > ==6792==    still reachable: 6,253,647 bytes in 26,607 blocks.
>
> And this is the legitimate memory that trackerd had allocated, around
> 6MB

Wow, that's a little! Thanks for free education. I now wanna play some
more with valgrind...


-- 
my place on the web:
floss-and-misc.blogspot.com