Re: svn commit: rev 3206

Justin Erenkrantz <jerenkrantz@apache.org> writes:

> On Sun, Sep 22, 2002 at 04:38:37PM +0100, Philip Martin wrote:
> > Heed the warning about memory use, I really mean it! If you try to
> > checkout a Subversion working copy with caching enabled you may well
> > run out of memory.
>
> Any idea why?

Yes, I know exactly why.

The entries caching implementation is fairly simple, it stores the
hash returned by svn_wc_entries_read in the cache. At present the
function svn_wc__entries_write clears the cache, because the hash it
it is given, or the data in the hash, is not always allocated from a
pool with a suitable lifetime. This means that read-write operation
rpeatedly allocates a new hash from the access baton pool.

Note that the function svn_wc_entry_modify fills the cache after
calling svn_wc__entries_write. It can do this because it knows the
hash is valid. The solution is to work on the other places that call
svn_wc__entries_write to ensure that the access baton pool is used to
allocate the hash contents. Then svn_wc__entries_write won't need to
clear the cache.

So the plan is, svn_wc_entries_read uses the access baton pool to fill
the hash initially (that's what happens now), then the code that
modifies the hash needs to ensure that it uses the access baton pool
to allocate the date (perhaps a helper function here), and finally
svn_wc__entries_write needs to stop clearing the cache.

I don't think it's that hard. I didn't do it r3206 because entries
caching was not really my aim with that patch. Also, that patch was
large enough, and took long enough, without it!

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org