> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: woensdag 14 januari 2015 12:00
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: r1557736 - Reduce memory footprint of the svnrdump dump
> handling...
>
> Hi Bert.
>
> The second part of this patch -- "Don't use editor pool as scratch pool"
-- looks
> right.
>
> The first part -- "Make file/dir pool within parent" -- looks unnecessary.
The
> editor driver is already passing in suitably scoped pools: a per-directory
pool to
> the 'open_directory' and 'add_directory' methods, and a per-file pool to
the
> 'open_file' and 'add_file' methods. At least the driver *should* be doing
so, and
> by inspection I see that ra_serf's implementation of svn_ra_replay[_range]
> actually is doing so.
>
> Does it make sense to remove this creation and deletion of our own
subpools
> here?
>
> I noticed this because make_dir_baton's and make_file_baton's doc strings
still
> say "Perform all allocations in POOL" but they don't.
Which editor driver does this right? ;)
Serf certainly didn't do this 'right' in 1.6-1.8, but I also fixed that on
the other side when I rewrote the driver for the new xml engine for 1.9.
Serf didn't provide short lived scratch pools and we had to fix a few of
those in patch releases because we had problems of too many files open
during update, etc.
(A driver with a pool per revision can give you tens of thousands of files
handled in a single pool)
If this problem is now properly fixed for all drivers, and it improves the
code we might want to remove some of those helper pools...
We probably have to reintroduce a similar pool system once we go to editor
v2, as that doesn't guarantee a depth first drive.
(But that will probably require a complete redesign of svnrdump anyway)
Bert
Received on 2015-01-14 12:10:24 CET