Julian Phillips <julian@xxxxxxxxxxxxxxxxx> wrote: > On Mon, 19 Mar 2007, Julian Phillips wrote: > > >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 ... I have to say, I'm looking at the refs.c code and I'm not seeing any reason why these need to be sorted. Granted, the current code expects that as it walks both get_packed_refs() and get_loose_refs() (as Junio pointed out), but change that code to toss both into a single refs hash table, with the elements being the current contents of struct ref_list. We already have the ISPACKED flag in the flags field to tell us if the ref is loose or not. When inserting a ref into the hash table you keep the loose version (either if its in the table, or the one being inserted). -- Shawn. - 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