Philip Martin <philip@codematters.co.uk> writes:
> > It would be nice if, in this case, our entries-caching used one
> > subpool per directory. I mean, once the update-editor's close_dir() is
> > called, couldn't we free an appropriate subpool containing the entries
> > file. That way, at any given time, we'd only have one "path" worth of
> > entries files cached in memory.
>
> There certainly is scope for change, particularly since we no longer
> store auth data in the working copy. It would mean giving up the
> "lock the entire tree before starting" behaviour, as that involves
> reading all the entries files and it's silly to do that and then
> discard the entries data.
>
> Commit might be more of a problem, since it must either hold the
> entries in memory or reread the entries files when bumping the
> revision post-commit. It might be possible to drop the entries for
> those parts of the tree that are not involved in the commit.
Urg. This is really one of those direct tradeoffs between speed and
memory usage, isn't it? Here we are, trying to speed things up as
much as possible... and yet there's a chance that by reducing this
particular sort of memory consumption, we get overall slowdowns.
Maybe this is one of those situations where we say "linear memory
growth as the wc grows" is okay, given the speed benefit.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 17:52:18 2003