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

Re: svn commit: r29773 - branches/in-memory-cache

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 7 Mar 2008 16:06:39 -0800

On Fri, Mar 7, 2008 at 3:48 PM, Blair Zajac <blair_at_orcaware.com> wrote:
> glasser_at_tigris.org wrote:
> > Author: glasser
> > Date: Fri Mar 7 10:23:54 2008
> > New Revision: 29773
> >
> > Log:
> > On the in-memory-cache branch:
> >
> > * README.branch
> > Add a README, including a basic outline of the API I'm going to add
> > and the implementation it's going to use.
> >
> >
> > Added:
> > branches/in-memory-cache/README.branch
> >
> > Added: branches/in-memory-cache/README.branch
> > URL: http://svn.collab.net/viewvc/svn/branches/in-memory-cache/README.branch?pathrev=29773
> > ==============================================================================
> > --- (empty file)
> > +++ branches/in-memory-cache/README.branch Fri Mar 7 10:23:54 2008
> > @@ -0,0 +1,102 @@
> > +This branch adds a simple in-memory cache library that handles
> > +annoying memory-management details for you. FSFS has several
> > +hand-written caches already; this will reduce duplicate code and make
> > +it easier to add more.
> > +
> > +NULL is a legitimate value. There is no cache_delete (but you can set
> > +to NULL, which may be good enough).
>
> It seems that any cache would want a cache_delete method. I've written a server
> that exposes svn via Ice and it would be handy to have a cache.

When we need it, sure. FSFS does have one bit of cache invalidation.

However, the whole reason that this data structure is needed at all is
that with APR pools, "deleting" (freeing memory) is non-trivial.

> What about adding some fields in the structures to make an LRU cache possible
> such as adding to the cache_entry the last time it was looked up. I guess one
> could also wrap the value in another value that has those fields, so leaving
> this alone would be good.

The plan as designed is already LRU (though at the "page" level of
granularity). If items_per_page=1 then this is a normal LRU cache,
but then you have the overhead of one pool (at least 8K) per item...

> But I think you'll always want a way of removing entries.

Not for some of the actual applications I am planning this for. There
are so many low-hanging trees of immutable but uncached data in
FSFS...

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-08 01:06:49 CET

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.