On Tue, Jul 12, 2011 at 12:41:35PM +0200, Jakub Narebski wrote:
> On Mon, 11 July 2011, Jeff King wrote:
>
> > There is sometimes a need to cache some information about an
> > object or set of objects persistently across git
> > invocations. The notes-cache interface can be used for this,
> > but it is very heavyweight and slow for storing small
> > values.
> >
> > This patch introduces a new API, object-cache, which stores
> > a mapping of objects to values in a concise and efficient
> > form. See the added API documentation for details.
> >
> > Signed-off-by: Jeff King <peff@xxxxxxxx>
> > ---
> > As I mentioned earlier, I wanted this to be generic and size-agnostic,
> > because I'd also like to try caching patch-ids for git-cherry.
>
> Could this API be generalized to support "reverse cache", for example
> to map Subversion revision numbers to Git revision identifiers (for
> git-svn)?
I hadn't really considered that. It definitely _could_ be done, but I'm
not sure if it's a good idea, for two reasons:
1. The in-memory store is based on decorate.[ch], which actually
stores pointers to objects instead of sha1s as keys. Which keeps
the hash entries a little smaller, and makes comparisons faster.
We can only take that shortcut because we know what the keys are
(i.e., objects, and the in-memory store gets pointers and the disk
store gets sha1s). So I have some fear that a more generalized form
may be a little slower.
2. The disk store uses a binary search over a sorted list of sha1s.
Generalizing this to "a sequence of bytes" would not be hard. But
we currently have the option of using the uniform distribution of
sha1 to make better guesses about our "middle" (see the comments in
sha1-lookup.c). That assumption does not hold over arbitrary bytes.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html