On Mon, 24 Aug 2009, Julian Phillips wrote: > On Mon, 24 Aug 2009, Daniel Barkalow wrote: > > > On Sun, 23 Aug 2009, Junio C Hamano wrote: > > > > > What is the point of not asking for the refs that we know are the same? > > > > This code is part of the original C implementation of fetch; I suspect the > > optimization was somehow in the shell version and made sense there, > > perhaps because there wasn't a quickfetch in the shell version or that > > there was some non-negligable per-ref cost in the code around there, since > > it was calling helper programs and such. > > I don't remember copying it from the shell version but my memory is terrible, > so I could easily be wrong. The relevant commit message was: > > "git-fetch2: remove ref_maps that are not interesting > > Once we have the full list of ref_maps, remove any where the local > and remote sha1s are the same - as we don't need to do anything for > them." > > So that doesn't help. I was very concerned about performance though (which > was why I wanted fetch in C in the first place), so may have added it to speed > up fetches that have only updated a few refs - and I assume that quickfetch > was something that came along later after you absorbed the work into the > transport series? Well... Johan Herland says he has to deal with repositories containing around 50000 refs. So in that case it is certainly a good idea not to send the whole 50000 refs back if only one or two (or a hundred) need to be updated. And quickfetch() won't help in that case since its purpose is only to determine if there is anything at all to update. > > Anyway, I think it makes sense to remove the filtering from > > transport_fetch_refs(), like your patch does. > > > > If it makes a difference for the actual protocol, fetch_refs_via_pack() > > could filter them at that stage. > > I think it would certainly be worth investigating the performance aspects ... > no time tonight, but maybe tomorrow. 50000 refs * 45 bytes each = 2.25 MB. That's all wasted bandwidth if only one ref needs updating. Nicolas -- 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