On Wed, Feb 15, 2012 at 4:14 PM, Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> wrote: > On Wed, Feb 15, 2012 at 12:01 PM, Nguyen Thai Ngoc Duy > <pclouds@xxxxxxxxx> wrote: >> On Wed, Feb 15, 2012 at 3:57 PM, Piotr Krukowiecki >> <piotr.krukowiecki@xxxxxxxxx> wrote: >>> Indeed, after gc the times went down: >>> 10s -> 2.3s (subdirectory) >>> 17s -> 9.5s (whole repo) >>> >>> 2 seconds is much better and I'd say acceptable for me. But my questions are: >>> - why is it so slow with not packed repo? >>> - can it be faster without repacking? >> >> gc does more than just repacking. If you still have the un-gc'd repo, >> Try these commands one by one, and time "git status" after each: >> >> - git pack-refs --all --prune >> - git reflog expire --all >> - git repack -d -l >> - git prune --expire >> - git rerere gc > > It will take some time but hopefully I'll have the stats for tomorrow. Here they are. I did 'status' three times to get reliable results and before each run have dropped caches. Backed up repository was copied before each 'status'. Full log is at http://pastebin.com/VmB7J9CJ git version 1.7.9.rc0.10.gbeecc Results after each command: status on whole repo: 18.5s - after git count-objects -v 16.0s - after git pack-refs --all --prune 20.2s - after git reflog expire --all 13.0s - after git repack -d -l 16.8s - after git prune --expire now 19.7s - after git rerere gc status on subdir: 9.7s - after git count-objects -v 9.2s - after git pack-refs --all --prune 9.3s - after git reflog expire --all 4.4s - after git repack -d -l 9.2s - after git prune --expire now 9.0s - after git rerere gc -- Piotr Krukowiecki -- 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