RE: svn commit: rev 6786 - trunk/subversion/libsvn_fs

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Tuesday, August 19, 2003 10:40 AM

> On Mon, Aug 18, 2003 at 10:09:52PM -0500, cmpilato@collab.net wrote:
> >...
> > I don't know if "suck up all of memory" is a realistic concern -- my
> > estimates have it maybe growing to 30M for a 20,000-path checkout --
> > but still, until the algorithm is smart enough to bound growth and
> > intelligent roll things out of the cache, it's a non-starter (which
> > is, I'm sure, something you agree with).
>
> All right... but what is the cache to do? What was measured as "poor" such
> that a cache might actually benefit?

The number of calls to open_path are numerous. This call is expensive.
Judging from a number of call graphs several functions use the same pattern.

If we could either reduce the number of times we traverse the expensive
codepath by caching or by consolidation functions, that would benefit
performance. Mike is a better judge on the complexity and downsides
of consolidation. We thought a simple cache would at least demonstrate
whether such a change would make a big difference.

> And could the "poor" measurement be fixed algorithmically rather than
> patched cache-ly?

Mike?

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 19 17:07:43 2003