Anders Kaseorg wrote:
> On Fri, 3 Dec 2010, Jonathan Nieder wrote:
>> Instead of looking up the commit to be matched exactly in the commits
>> hash table, this makes a linear search.
[...]
> 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).
Thanks for checking. Makes sense.
>>> - 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).
Depends on what "Don't lookup commits" means, I suppose. I
think the difference between _ref and _rawref is
if (!(flags & DO_FOR_EACH_INCLUDE_BROKEN)) {
if (entry->flag & REF_BROKEN)
return 0; /* ignore dangling symref */
if (!has_sha1_file(entry->sha1)) {
error("%s does not point to a valid object!", entry->name);
return 0;
}
}
so if I understand correctly, for_each_ref would still allow one to
get away without unpacking the objects. Is that correct?
--
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