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 4:14 PM, Piotr Krukowiecki
[off-list ref] wrote:
On Wed, Feb 15, 2012 at 12:01 PM, Nguyen Thai Ngoc Duy
[off-list ref] wrote:
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help