Piotr Krukowiecki [off-list ref] writes:
On Wed, Feb 15, 2012 at 8:03 PM, Jeff King [off-list ref] wrote:
quoted
On Wed, Feb 15, 2012 at 09:57:29AM +0100, Piotr Krukowiecki wrote:
quoted
I notice that you're still I/O bound even after the repack:
quoted
$ time git status -- .
real 0m2.503s
user 0m0.160s
sys 0m0.096s
$ time git status
real 0m9.663s
user 0m0.232s
sys 0m0.556s
Did you drop caches here, too?
Yes I did - with cache the status takes something like 0.1-0.3s on whole repo.
So umm, I'm not sure that leaves anything to be improved.
I looked at some strace dumps, and limiting the status to a subdirectory
(in my case, '-- t' in git.git) does omit the lstat()s on uninteresting
parts of the index-listed files, as well as the getdents() (i.e.,
readdir()) for parts of the tree that are not interesting.
BTW, some other parts of git-status's display may be responsible for the
amount of data it pulls from disk. In particular, the "Your branch is
ahead" display requires computing the merge-base between HEAD and
@{upstream}. If your @{upstream} is way ahead/behind, or points at a
disjoint chunk of history, this may mean essentially pulling all of the
involved history from disk. If my memory of pack organization serves
right, the commit objects involved would essentially be spread across
the whole pack (corresponding to "time") and thus this operation would
more or less load the entire pack from disk.
--
Thomas Rast
trast@{inf,student}.ethz.ch
On Thu, Feb 16, 2012 at 3:05 PM, Thomas Rast [off-list ref] wrote:
Piotr Krukowiecki [off-list ref] writes:
quoted
On Wed, Feb 15, 2012 at 8:03 PM, Jeff King [off-list ref] wrote:
quoted
On Wed, Feb 15, 2012 at 09:57:29AM +0100, Piotr Krukowiecki wrote:
quoted
I notice that you're still I/O bound even after the repack:
quoted
$ time git status -- .
real 0m2.503s
user 0m0.160s
sys 0m0.096s
$ time git status
real 0m9.663s
user 0m0.232s
sys 0m0.556s
Did you drop caches here, too?
Yes I did - with cache the status takes something like 0.1-0.3s on whole repo.
So umm, I'm not sure that leaves anything to be improved.
But even with caches time on small directory is only half of time on whole repo:
0.15s vs 0.07s
I looked at some strace dumps, and limiting the status to a subdirectory
(in my case, '-- t' in git.git) does omit the lstat()s on uninteresting
parts of the index-listed files, as well as the getdents() (i.e.,
readdir()) for parts of the tree that are not interesting.
Same in my case.
I've run strace with -c which shows system calls times. As I
understand the results the time used by lstat() is very small. With
dropped caches:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
90.70 0.065108 3 25361 12 lstat
6.78 0.004869 1 6534 getdents
1.94 0.001392 0 6964 3238 open
0.27 0.000194 0 3726 close
BTW, some other parts of git-status's display may be responsible for the
amount of data it pulls from disk. In particular, the "Your branch is
ahead" display requires computing the merge-base between HEAD and
@{upstream}. If your @{upstream} is way ahead/behind, or points at a
disjoint chunk of history, this may mean essentially pulling all of the
involved history from disk. If my memory of pack organization serves
right, the commit objects involved would essentially be spread across
the whole pack (corresponding to "time") and thus this operation would
more or less load the entire pack from disk.
I don't think this is the case - I'm using git-svn and thus have no
upstream in git meaning.
--
Piotr Krukowiecki