On Mon, Mar 23, 2009 at 07:50:33PM -0300, Martín Ferrari wrote:
> $ perl test
> Reusing the SVN object
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> martin 20600 0.0 0.6 21380 6592 pts/7 S+ 19:41 0:00 perl
> test
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> martin 20600 42.0 5.2 73560 53528 pts/7 S+ 19:41 0:00 perl
> test
> NOT reusing the SVN object
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> martin 20600 54.0 0.6 21524 6908 pts/7 S+ 19:41 0:00 perl
> test foo
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> martin 20600 94.0 2.2 41856 22608 pts/7 S+ 19:41 0:01 perl
> test foo
>
> As you can see, while destroying the SVN object on each step alleviates
> the problem, there's still a very noticeable increment in memory usage,
> and a serious degradation in performance.
Interestingly, the results are reversed with current libsvn-perl.
Here's a run of the same tests, but with an additional scenario of
allocating a new default pool inside the loop, so it gets freed on
exiting the scope.
Added scenario:
} elsif ($arg && $arg == 2) {
warn "Using a new subpool for each loop\n";
open FOO, "> /dev/null";
my $ctx = new SVN::Client();
system("ps u $$");
foreach(1..500) {
my $pool = SVN::Pool->new_default;
#$ctx->ls('file:///tmp/foo', 'HEAD', 0);
$ctx->cat (\*FOO, $path, 'HEAD', $pool);
}
system("ps u $$");
Reusing the SVN object
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22209 0.0 0.2 145304 16532 pts/8 S+ 21:08 0:00 perl foo.pl
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22209 0.0 0.8 208760 65292 pts/8 S+ 21:08 0:00 perl foo.pl
NOT reusing the SVN object
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22209 0.0 0.2 145352 17452 pts/8 S+ 21:08 0:00 perl foo.pl 1
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22209 84.0 1.9 306856 161396 pts/8 S+ 21:08 0:00 perl foo.pl 1
Using a new subpool for each loop
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22209 90.0 0.2 145364 17288 pts/8 S+ 21:08 0:00 perl foo.pl 2
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22209 102 0.3 163460 24688 pts/8 S+ 21:08 0:01 perl foo.pl 2
Again with 500 → 1000.
Reusing the SVN object
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22319 0.0 0.2 145304 16488 pts/8 S+ 21:09 0:00 perl foo.pl
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22319 0.0 1.3 254424 106940 pts/8 S+ 21:09 0:00 perl foo.pl
NOT reusing the SVN object
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22319 0.0 0.2 145364 17396 pts/8 S+ 21:09 0:00 perl foo.pl 1
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22319 141 3.6 450660 298396 pts/8 S+ 21:09 0:01 perl foo.pl 1
Using a new subpool for each loop
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22319 74.0 0.2 145364 17176 pts/8 S+ 21:09 0:01 perl foo.pl 2
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jamessan 22319 85.5 0.3 163460 24384 pts/8 S+ 21:09 0:01 perl foo.pl 2
Notice how the memory is fairly stable with the local pool?
Whether you use SVN::Pool->new_default_sub or SVN::Pool->new_default
depends on your use case, but it seems clear that proper pool use is the
right way to manage memory.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
