On Thu, Dec 11, 2014 at 6:34 AM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > I looked at this more in depth today and I found that the bottleneck is > --thin. I tried git send-pack, which does not use --thin by default, > which led me to further testing. A particular push went from 24 seconds > with --thin to 4 seconds without. > > I agree that the large number of refs is at least part of the problem, > because reducing the number of refs has a slight but noticeable impact. > It's also the factor I can least control. > > I have a patch which allows per-remote configuration of whether to use > thin packs (which I will send shortly), but I'm wondering if we can do > better, especially since --thin is the default. It looks like --thin > forces pack-objects to do its own lookup (essentially a rev-list) > instead of using the values provided on stdin. It could be a regression by fbd4a70 (list-objects: mark more commits as edges in mark_edges_uninteresting - 2013-08-16). That commit makes --thin a lot more agressive (reading lots of trees). You can try to revert that commit (or use a git version without that commit) and see if it improves performance. If so, we probably want to enable that code for shallow repos only. -- Duy -- 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