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

Re: [PATCH] Pools memory reuse

From: Kirby C. Bohling <kbohling_at_birddog.com>
Date: 2002-02-07 04:04:33 CET


        I tinkered with the patch, using the following script attached to but
number 622 with the exception that the outer loop iterates from a-m, and
the inner loop iterates from 1-14. Before the patch, and after the
patch have behave identically as nearly as I can tell. Both of them
consume roughtly 27,400K of VM just before the commit, and appear to
grow at the same rate (the rate is an anecdotal test, not scientific).
I setup top and watch the memory growth by sorting with option M and set
the delay to 0.5 seconds, then watch the screen. I ran the script 5
times pre and post patch, all of them seemed the same.

        I am not sure that this is a good test case however. As memory isn't
getting freed and reused because it is only in one directory. It is
allocating a ton of memory in one particular pool. I will continue
looking at it and see if I can find a better test case.

I can't tell from the patch (I don't understand apr's allocation scheme
at all) what kind of cases I should see changes for. I can build a much
better test case if I know what to look for. Can you describe an a pool
layout where the behaviour should be different, I can try and build
directory structure where the pools should show the new behavior.

I mean does it behave better when there are lots of little subpools
freed? Does it fix cases where a handful of large subpools are freed?
Does it fix cases where some large and some small pools are freed
better? Does it handle cases where equally sized siblings are freed? I
can easily build any of those test cases and measure them. I probably
will later tonight or tomorrow, but if you have specific cases you want
tested please let me know. For the one simple test case, it didn't do
much, but I am not sure it was the right test.



Sander Striker wrote:
> Hi,
> This is really an APR patch, but the only thing where this
> will show a difference (I hope) is Subversion. Apache
> generally only does small allocations, therefore the
> memory usage seen there is not as bad as with Subversion.
> Anyhow, I would very much like someone who did memory
> usage analysis on subversion before (Hi Kirby) to test
> this patch, before I throw it on dev@apr. If it doesn't
> show a significant difference, it isn't worth it.
> Sander
> PS. This is one of my not so great patches (I'll clean
> it up if this seems like a path to follow).
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006

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.