Having got a C implementation of fetch far enough to be able to tell me
that I'm up-to-date (when using git:// and not using remotes or branches
files) I thought I'd compare performance with the fetch--tool based
version. I was a bit surprised at what I saw.
Hot-cache time went from ~30s to ~3s, which didn't seem too bad. However
what did puzzle me was where the C version was spending it's time. Being
a work in progress it's a bit chatty in places, but there is an up-front
delay of just over 1s (i.e. before my first message, which is the name of
the remote to fetch).
A bit of investigation showed this to be due to the first attempt to read
a ref causing the packed refs to be loaded. In my test repo the
packed-refs file has over 9000 entries, but I still thought that it would
load faster than that. It turns out that the overhead is from sorting the
refs when building the ref_list. If I remove the code for sorting the
entries I lose that initial 1s delay, without appearing to break anything
in the fetch. However I assume that it's there for a reason ...
So my questions are:
1) what have I broken by removing the sort?
2) is it worth trying to optimise the sort?
--
Julian
---
<SpanKY> http://www.ananova.com/news/story/sm_806582.html?menu=news.quirkies
<Mr_Bones_> SpanKY: my life would have been much improved without that
link.
-
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