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. > I'd be more interested in why auto-gc does not kick in (or whther it should). I don't have any specific options set, so default values should be used. I'm using git-svn though, so my workflow looks like this: git svn fetch + git svn rebase ... git operations like commit, cherry-pick, rebase ... git svn dcommit Not sure if that matters. I remember that I've seen auto-gc being run several times in the past - I think after svn fetch/rebase. I'm also using git-new-workdir and have 2 extra workdirs. >> - even with packed repo, the time on small subdirectory is much higher >> than I'd expect given time on whole repo and subdirectory size - why? > > Hard to say without measuring. I just notice that I missed your mail > with profiling results. I will have a look, but just in case, is the > repository publicly available? Unfortunately it's not public. I can do some measuring if someone tells me what to do. -- 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