"Garrett Rooney" <rooneg@electricjellyfish.net> writes:
> On 5/4/06, Eric Gillespie <epg@pretzelnet.org> wrote:
> > Hmm. Only the entries for the directory currently being scanned
> > and all its parents need be in memory at once. There should be a
> > subpool for each directory, i would think. If it's growing
> > without bound, it sounds to me like *all* entries are staying in
> > memory. In other words, given
> >
> > wc
> > wc/bin
> > wc/bin/ls
> > wc/bin/sh
> >
> > wc/bin/ls entries should be in a pool that is freed before moving
> > on to wc/bin/sh.
> >
> > > either that or you get unacceptable speed hits from parsing the
> > > entries file multiple times.
> >
> > Once svn is finished printing status for wc/bin/ls, it will never
> > need those entries again.
>
> Sure, but doing a pool per directory means you've just multiplied your
> memory usage for small and medium sized trees dramatically, since each
> pool allocates 8k of memory.
Hrm. The status quo, with svn checkout of a large trees using
unacceptably large amounts of memory (and apparently status -u
also), is unacceptable. If the only alternative is to waste 8K
for each subdirectory, it may be best to pay that cost. I'm not
sure these are the only choices. I have not yet looked into this
in any detail in over a year, when i whined and hoped someone
else would take care of it :).
> That also assumes that we never make multiple passes, and I'm
> not sure that's the case.
I can't imagine why we'd make a second pass. Once a file has
been checked out or had its status checked, we're done with it.
Once we've checked out or checked status of everything in a
subdirectory, we're done with that set of entries.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 5 02:14:05 2006