Philip Martin <philip@codematters.co.uk> writes:
> <sussman@collab.net> writes:
>
> > So what's up with this magical 40 meg client size? It shows up in
> > every command -- checkout, update, status, commit!
> >
> > Is it the size of 5000 entries files loaded into memory -- about
> > 42,000 individual entry structures?
>
> Yes, that's correct. Any operation that opens the whole tree reads
> all the entries files at the start. I suppose read operations could
> be made more streamy (although it may well not be a trivial change),
> but would we want to do that for write operations? At present if part
> of a wc needs 'svn cleanup' an update/commit operation fails before
> doing any network stuff, in the past it would fail part way through
> when it ran into the locked directory.
>
> As I recall I brought up the question of memory use when I introduced
> the entries caching.
Philip -- I don't understand... in the case of checkout/update, why
would we ever get to a point where we're holding *every* entries file
in memory?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 19 17:40:35 2003