Re: [Evolution-hackers] Memory testing > 15,000 headers
- From: "Serjan Pruis a.k.a. Smartuser" <smartuser gmail com>
- To: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Memory testing > 15,000 headers
- Date: Tue, 22 Aug 2006 18:53:44 +0200
Sorry Philip,
What does the valgrind hack do?
On Tuesday 22 August 2006 17:26, Philip Van Hoof wrote:
> On Tue, 2006-08-22 at 16:54 +0200, Philip Van Hoof wrote:
> > You can repeat this testing using the tests in the tinymail framework:
>
> Also make sure you read this page:
>
> http://tinymail.org/trac/tinymail/wiki/HelpMemoryTesting
>
> Don't forget to perform G_SLICE=always-malloc and G_DEBUG=gc-friendly if
> you want to check for leaks. I tested it quite some times and it doesn't
> look like tinymail nor Camels IMAP provider are leaking memory in their
> crucial memory-eating folder-summary related parts.
>
> The NNTP provider, however, definitely *is* leaking here. I haven't yet
> tested the other providers. I will of course investigate and try to spot
> the leak soon.
>
>
>
> My Post Scriptum reasoning for the mmap crap and these measurements:
>
> I know this sounds like yet another round of tinymail "hey ho hey ho,
> hey look hey ho!"-E-mailing.
>
> Nevertheless, tinymail can be very useful for testing Camel and more
> specifically Camels memory usage. I do recommended Evolution developers
> to use tinymail for getting the memory usage of Camel down. By just the
> numbers that I'm measuring and calculating, it's no surprise to me that
> Evolution consumes as much memory as it does.
>
> Also try this valgrind hack: http://pvanhoof.be/files/project1.tar.gz
>
> However, I do believe lots of improvements can be made. Sadly most of
> the improvements mean irreversible and hard to make design decisions and
> changes to Camel that wont be backward compatible.
>
> I'm indeed posting these results in the hopes that people someday find
> the courage and reasoning for starting the Disk Summary branch. I'm
> posting in the hopes that when people will be redesigning Camel (or
> libspruce), that they will understand where exactly memory is being
> consumed *today*.
>
> I indeed ALSO want to get memory consumption per active/open folder
> down. The less memory one such folder consumes, the larger the folder
> can be. The lesser memory the mobile device vendor must install. The
> cheaper the per-unit factory cost will be and more importantly from a
> technical point of view: the fewer power it will consume.
>
> The more interesting tinymail (and therefore also Camel) will be for
> mobile purposes.
>
> > svn co https://svn.tinymail.org/svn/tinymail && cd tinymail/trunk
> > ./autogen.sh --prefix=/opt/tinymail --enable-tests --with-platform=gpe
> > make && make install
> >
> > # Getting the headers locally (this will work out of the box, the
> > # account information is in the source code indeed)
> > /opt/tinymail/bin/memory-test --online
> >
> > valgrind --tool=massif /opt/tiynymail/bin/memory-test -c /tmp/tinymail.0
> >
> > You will mostly be using this code for this specific test:
> >
> > http://svn.tinymail.org/svn/tinymail/trunk/tests/memory/memory-test.c
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]