Thread (10 messages) flat view 10 messages, 4 authors, 2016-06-15

Re: git status: small difference between stating whole repository and small subdirectory

From: Piotr Krukowiecki <hidden>
Date: 2016-06-15 22:53:05

On Wed, Feb 15, 2012 at 12:01 PM, Nguyen Thai Ngoc Duy
[off-list ref] wrote:
On Wed, Feb 15, 2012 at 3:57 PM, Piotr Krukowiecki
[off-list ref] wrote:
quoted
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.

quoted
- 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help