[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [serf-dev] Re: What stands between us and branching 1.7?

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Sun, 23 Jan 2011 19:10:32 +0100

On 23.01.2011 18:06, Justin Erenkrantz wrote:
> On Sun, Jan 23, 2011 at 8:42 AM, Stefan Küng<tortoisesvn_at_gmail.com> wrote:
>> Ok, tested with serf from the 0.7.x branch: memory rise is still higher than
>> with neon, indicating that there's still some (small) memory leak somewhere.
>> But checkouts and updates of even larger projects succeed without using up
>> all available memory as before.
>> To compare: checkout of the TSVN source including all externals with serf
>> uses up about 40MB more RAM than when using neon. I'd say that's ok.
>
> Does the memory keep going up? Or, does it reach a steady point? I'd
> expect that ra_serf would use a bit more memory than ra_neon as it has
> to manage a lot more than what neon has to do.
>
> As a point of reference, on Mac OS X 10.6, svn 1.6.x with ra_serf
> checking out svn trunk peaks at 81MB, while ra_neon peaks at 12MB.

I can't really say for sure if serf memory keeps going up or not. I was
testing with TSVN and there the memory has to keep going up since all
the output is stored in memory for the UI controls to show to the user.
I can only say for sure that the memory for both neon and serf goes up
at approximately the same rate. Only with serf, memory goes up at the
beginning very fast until about 40-50MB more than with neon, but then
keeps that 'distance' (well, almost: the distance increases a little
bit, but not much - around 8kbytes per two seconds) to neon until the end.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2011-01-23 19:11:23 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.