[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 3214 - branches/issue-749-caching/subversion/libsvn_wc

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-09-24 03:10:55 CEST

philip@tigris.org writes:

> Author: philip
> Date: 2002-09-23 19:35:01 -0500 (Mon, 23 Sep 2002)
> New Revision: 3214
> Modified:
> branches/issue-749-caching/subversion/libsvn_wc/adm_ops.c
> branches/issue-749-caching/subversion/libsvn_wc/entries.c
> branches/issue-749-caching/subversion/libsvn_wc/lock.c
> Log:
> Enable full read-write entries caching. Hey, it passes the regression
> tests - commit it!

First the good news. Check-out of a repository containing 200 files in
a single directory runs twice as fast with read-write entries caching.
It doesn't exhibit the gradual slowdown associated with repeatedly
parsing the entries file, although it is still repeatedly writing the

Now the bad news. Memory usage is a problem. Access batons tend to
live for the duration of operations like checkout, so the caches have
to use long-lived pools and memory usage tends to increase with the
size of the working copy. Check-out of the subversion trunk uses over
100MB with APR pool debugging enabled. Now with a bit of work we can
probably reduce the rate at which it grows, but I don't immediately
see how to eliminate the growth. It's not really surprising, when I
first considered using access batons to cache entries I suggested that
it might be a problem


Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 03:11:31 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.