On Wed, Oct 22, 2003 at 10:49:29AM -0500, Ben Collins-Sussman wrote:
> 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.
>
There's a middle ground: victimize certain entries from the cache.
IIRC, it wasn't the cost of reading each entries file once or twice
that was killing us, it was the cost of reading it N times per file!
Even with a simple FIFO cache (like the DAG's), we might see significant
performance improvements with better upper bounds on memory requirements.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 18:28:43 2003