Re: r1557736 - Reduce memory footprint of the svnrdump dump handling...

Bert Huijben wrote:
> Julian Foad wrote:
>> The [...] driver is already passing in suitably scoped pools
>> [...] 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?
[...]
>
> Which editor driver does this right? ;)

By inspection, it appears RA-svn and RA-local have done this right since pre-1.0.

> 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.

OK, thanks for explaining. I have updated the log messages for

r1499863 "Convert ra_serfs 'svn_ra_replay' support to the transition based xml parser."
r1557736 "Reduce memory footprint of the svnrdump dump handling..."

to mention this.

> 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. [...]
>
> 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...

OK, thanks. r1651690.

> 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)

Yes, pool handling will have to be completely different if Ev2 has a completely different driving order.

- Julian
Received on 2015-01-14 16:22:10 CET