Sander,
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.
Thanks,
Kirby
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