On Fri, 3 Dec 2010, Jonathan Nieder wrote:
> - static?
> - the convention in git is to leave off the zero-initializers
> for bss-allocated vars (static and globals).
Will fix.
> The usual convention is to use !hashcmp(...) to match the !strcmp(...)
> idiom.
Will fix (I hate that idiom, but yeah, match existing style).
> > + for (e = names; e; e = e->next) {
> > + if (!hashcmp(e->peeled, cmit->object.sha1) &&
> > + replace_name(n, e->prio, e->sha1, &e->tag))
> > + n = e;
> > + }
>
> Instead of looking up the commit to be matched exactly in the commits
> hash table, this makes a linear search.
>
> No change to the assymptotic running time, but would this make things
> much slower in the case of many tags? How many before it's a problem
> (if ever)?
I donât think itâs ever a problem: in my repository with 1800 tags on a
warm cache, that loop accounts for about 0.1% of even the fastest
non-exact-match query (a commit right after a tag).
> (If it's a problem in ordinary cases, I think the optimization could be
> limited to --exact-match pretty easily.)
Then youâd lose the speedup in the case where --exact-match wasnât
specified but a tag happens to match exactly (which isnât critical, but
seemed nice).
> > - for_each_ref(get_name, NULL);
> > + for_each_rawref(get_name, NULL);
>
> Orthogonal change snuck in?
This does fall under the category of âDonât lookup commits,â and is
necessary to get the speedup (otherwise for_each_ref has already looked up
the commits that the rest of the patch is trying to avoid looking up).
But I could split it out if you want.
Anders
--
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