[TOPIC 8/17] Push performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



1. Terry: Chrome has 500MB file pushed up. Using Gerrit, feature work becomes stale over a few days, then push. For a few months pushes would push gigabytes of data.

2. Stolee: where we do the tree walk, we are doing it from the merge base. Jonathan N: Minh rescued us by advertising more .have refs to avoid it being pushed. In protocol V2 for push there are 3 major changes proposed: one, abbreviating ref advertisement; two, adding negotiation; three, push to fast moving ref if you don’t care if its a fast forward. Are there other cases?

3. Minh: performance on reachability. Would help to know what branch you are pushing.

4. Peff: I might be pushing a random sha, without a branch.

5. Brian: I’ve seen cases with 80k refs, we tried then to send minimal amounts of objects. We spend a lot of time negotiating, to eventually only send 4 objects. It’s not very efficient, you could just spend less time on that and send a few more objects.

6. Minh: can we invert the pattern? Just send the new thing, and then the server says give me more.

7. Peff: You’ll get N+1 issues.

8. Jonathan N: I like Jeff Hostetler’s idea in Zoom chat. You can look at the branch and see when the author changes and use that as a crude heuristic to ask the server if they have that commit.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux