[PATCH] remove over-eager caching in sha1_file_name

From: Jeff King <peff@peff.net>
Date: May 22, 2010, 06:59 UTC
Message-ID: <20100522065942.GB11335@coredump.intra.peff.net>
In-Reply-To: <20100522064308.GA11335@coredump.intra.peff.net>

On Sat, May 22, 2010 at 02:43:08AM -0400, Jeff King wrote:

Show 12 quoted lines

> This patch takes the minimalist fix. It retains the caching,
> but checks the validity of our object directory against the
> one cached in environment.c, which adds only a single
> function call and a pointer comparison to the fast path.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> As I noted above, this is the minimal fix. I think it would be more
> readable, though, to simply remove this caching layer altogether and use
> a static buffer. I suspect the original was just trying to avoid the
> slow getenv() call, which is no longer an issue now. We can probably
> afford an snprintf. I'll post that patch shortly.

Actually, thinking on it more, micro-optimizing this is really pointless. I was thinking that it would get called a lot, so we need to care. But the next step is almost certainly to open, mmap, and zlib decompress the resulting object, which is way more expensive.

So here it is with caching ripped out. More readable and more robust, and I'm sure we can afford an extra strlen() and memcpy() on each object lookup.

-- >8 --
Subject: [PATCH] remove over-eager caching in sha1_file_name

This function takes a sha1 and produces a loose object filename. It caches the location of the object directory so that it can fill the sha1 information directly without allocating a new buffer (and in its original incarnation, without calling getenv(), though these days we cache that with the code in environment.c).

This cached base directory can become stale, however, if in a single process git changes the location of the object directory (e.g., by running setup_work_tree, which will chdir to the new worktree).

In most cases this isn't a problem, because we tend to set up the git repository location and do any chdir()s before actually looking up any objects, so the first lookup will cache the correct location. In the case of reset --hard, however, we do something like:

  1. look up the commit object

  2. notice we are doing --hard, run setup_work_tree

  3. look up the tree object to reset

Step (3) fails because our cache object directory value is bogus.

This patch simply removes the caching. We use a static buffer instead of allocating one each time (the original version treated the malloc'd buffer as a static, so there is no change in calling semantics).

Signed-off-by: Jeff King <peff@peff.net>
---
 sha1_file.c |   28 +++++++++++++++-------------
 1 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index d8e61a6..e42ef96 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -102,20 +102,22 @@ static void fill_sha1_path(char *pathbuf, const unsigned char *sha1)
  */
 char *sha1_file_name(const unsigned char *sha1)
 {
-	static char *name, *base;
+	static char buf[PATH_MAX];
+	const char *objdir;
+	int len;
 
-	if (!base) {
-		const char *sha1_file_directory = get_object_directory();
-		int len = strlen(sha1_file_directory);
-		base = xmalloc(len + 60);
-		memcpy(base, sha1_file_directory, len);
-		memset(base+len, 0, 60);
-		base[len] = '/';
-		base[len+3] = '/';
-		name = base + len + 1;
-	}
-	fill_sha1_path(name, sha1);
-	return base;
+	objdir = get_object_directory();
+	len = strlen(objdir);
+
+	/* '/' + sha1(2) + '/' + sha1(38) + '\0' */
+	if (len + 43 > PATH_MAX)
+		die("insanely long object directory %s", objdir);
+	memcpy(buf, objdir, len);
+	buf[len] = '/';
+	buf[len+3] = '/';
+	buf[len+42] = '\0';
+	fill_sha1_path(buf + len + 1, sha1);
+	return buf;
 }
 
 static char *sha1_get_pack_name(const unsigned char *sha1,

-- 
1.7.1.227.ge187a.dirty