git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Performance regression in `git branch` due to ref-filter usage

From
Jeff King <peff@peff.net>
Date
May 17, 2017, 14:04 UTC
Message-ID
<20170517140417.kwzznw4su36k6pxv@sigill.intra.peff.net>
In-Reply-To
<dfc3a334-8047-26b0-1142-81c703010507@alum.mit.edu>
On Wed, May 17, 2017 at 01:14:34PM +0200, Michael Haggerty wrote:
Show 16 quoted lines
> While working on reference code, I was running `git branch` under
> `strace`, when I noticed that `$GIT_DIR/HEAD` was being `lstat()`ed and
> `read()` 121 times. This is in a repository with 114 branches, so
> probably it is being run once per branch. The extra work makes a
> measurable difference to the (admittedly, short) runtime.
> 
> As recently as 2.12.3 the file was only read 4 times when running the
> same command [1].
> 
> The regression bisects to
> 
>     949af0684c (branch: use ref-filter printing APIs, 2017-01-10)
> 
> It would be nice if these extra syscalls could be avoided.
> 
> I haven't checked whether other commands have similar regressions.

It looks like it's part of populate_value(). Each ref checks %(HEAD), and resolve HEAD individually to see if we're it. So it probably doesn't affect other commands by default (though you could specify %(HEAD) manually via for-each-ref).

The solution is to cache the value we read and use it to compare against each ref. I'm not sure if we can do something more elegant than the patch below, which just caches it for the length of the program.

> [1] One wonders why the file has to be read more than once, but that's a
> different story and probably harder to fix.

The other ones seem to come from wt_status code, as part of get_head_description().

---
diff --git a/ref-filter.c b/ref-filter.c
index 1fc5e9970..947919fc4 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1284,6 +1284,20 @@ static const char *get_refname(struct used_atom *atom, struct ref_array_item *re
 	return show_ref(&atom->u.refname, ref->refname);
 }
 
+static int head_matches(const char *refname)
+{
+	static int initialized;
+	static char *head;
+
+	if (!initialized) {
+		unsigned char sha1[20];
+		head = resolve_refdup("HEAD", RESOLVE_REF_READING, sha1, NULL);
+		initialized = 1;
+	}
+
+	return head && !strcmp(refname, head);
+}
+
 /*
  * Parse the object referred by ref, and grab needed value.
  */
@@ -1369,12 +1383,7 @@ static void populate_value(struct ref_array_item *ref)
 		} else if (!deref && grab_objectname(name, ref->objectname, v, atom)) {
 			continue;
 		} else if (!strcmp(name, "HEAD")) {
-			const char *head;
-			unsigned char sha1[20];
-
-			head = resolve_ref_unsafe("HEAD", RESOLVE_REF_READING,
-						  sha1, NULL);
-			if (head && !strcmp(ref->refname, head))
+			if (head_matches(ref->refname))
 				v->s = "*";
 			else
 				v->s = " ";
Previous: Michael HaggertyNext: Jeff King
Message 2 of 3 in “Performance regression in `git branch` due to ref-filter usage”
  1. Michael HaggertyMay 17, 2017
  2. Jeff KingMay 17, 2017
  3. ref-filter: resolve HEAD when parsing %(HEAD) atomJeff King, May 19, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.