On 10/03/2011 08:12 PM, Martin Fick wrote: > On Friday, September 30, 2011 04:06:31 pm Martin Fick wrote: >> OK, I narrowed it down I believe. If I comment out the >> invalidate_cached_refs() line in write_ref_sha1(), it >> speeds through this section. >> >> I guess this makes sense, we invalidate the cache and >> have to rebuild it after every new ref is added? >> Perhaps a simple fix would be to move the invalidation >> right after all the refs are updated? Maybe >> write_ref_sha1 could take in a flag to tell it to not >> invalidate the cache so that during iterative updates it >> could be disabled and then run manually after the >> update? > > Would this solution be acceptable if I submitted a patch to > do it? My test shows that this will make a full fetch of > ~80K changes go from 4:50min to 1:50min, No, no, no. Let's fix up the refs cache once and for all and avoid adding special case code all over the place. * With minor changes, we can make it possible to invalidate single refs instead of the whole the refs cache. And we can teach the refs code to invalidate refs by itself when necessary, so that other code can become stupider and more decoupled from the refs code. * With other minor changes (mostly implemented), we can support a partly-sorted refs list that decides intelligently when to resort itself. This will give most of the performance benefit of circumventing the refs cache API with none of the chaos. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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