From: mhagger@alum.mit.edu Date: Tue, 22 May 2012 13:16:06 GMT Subject: [PATCH] find_containing_dir(): allocate strbuf less extravagantly Message-ID: <1337692566-3718-1-git-send-email-mhagger@alum.mit.edu> From: Michael Haggerty It might seem like allocating a fixed-length buffer of uninitialized memory should be pretty cheap even if the buffer is of size PATH_MAX. But empirically, it is measurably faster to allocated only the strlen of the input string. Thanks to Peff for pointing out a performance regression in this area that might be fixed by this patch. Signed-off-by: Michael Haggerty --- I am not able to reproduce performance regressions as bad as those observed by Peff. It seems to depend on the amount of memory pressure. The smaller regression that I *did* see is fixed by this patch, reducing the time for "git fetch . refs/*:refs/*" from 10.1 s to 9.3 s. The change is sensible in any case, but we will have to wait for Peff's verdict about whether it fixes the whole problem for him, too. refs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs.c b/refs.c index d6bdb47..fffbb17 100644 --- a/refs.c +++ b/refs.c @@ -383,7 +383,7 @@ static struct ref_dir *find_containing_dir(struct ref_dir *dir, { struct strbuf dirname; const char *slash; - strbuf_init(&dirname, PATH_MAX); + strbuf_init(&dirname, strlen(refname)); for (slash = strchr(refname, '/'); slash; slash = strchr(slash + 1, '/')) { struct ref_dir *subdir; strbuf_add(&dirname, -- 1.7.10