Junio C Hamano <gitster@xxxxxxxxx> wrote: >Martin Fick <mfick@xxxxxxxxxxxxxx> writes: > >> Does anyone have any hints as to what might be wrong with >> the receiving end algorithm that would cause a small change >> to use so much CPU? Is there anything that can be done >> about it? I noticed that the --all option will effectively >> feed all the 100K refs to rev-list, is this really >> necessary? > >It is trying to minimize the transfer cost. By showing a ref to the >sending side, you prove you have chains of commits leading to that >commit >and the sender knows that it does not have to send objects that are >reachable from that ref. One thing you could immediately do is de-dup >the >100k refs but we may already do that in the current code. I am sorry I don't quite understand what you are suggesting is taking up the CPU time? It doesn't take that much CPU just to gather 100refs and send them to the other side, that would be i/o bound. Could you explain what is happening on the receiving side that is so time consuming? >> Are there any tests that I can perform to help >> debug this? > >You do not need to "help debug" it. It's cause is already known: the >receiver exposes too many refs to the sending side. But wouldn't that cause excessive CPU for the sending side? It did with jgit, but that can be remedied with a simple jgit fix. Thanks for your insights, -Martin Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum -- 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