Paweł Sikora [off-list ref] writes:
Umm, there's a gem here that the thread missed so far:
my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
^^^^^^^^^
There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
res = sequencer_pick_revisions(&opts);
int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
[...]
return pick_commits(todo_list, opts);
}
static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.
--
Thomas Rast
tr@thomasrast.ch
On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast [off-list ref] wrote:
Paweł Sikora [off-list ref] writes:
quoted
Umm, there's a gem here that the thread missed so far:
quoted
my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
^^^^^^^^^
There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
res = sequencer_pick_revisions(&opts);
int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
[...]
return pick_commits(todo_list, opts);
}
static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.
That's something to optimize, but it's single commit picking,
sequencer_pick_revisions() should call single_pick() instead of
pick_commits().
The read+close on the whole checkout looks like there's problem with
refresh operation and git decides to read up and verify sha-1 by
content. Pawel, if you run "strace git update-index --refresh" twice,
does it still show 1 stat + 1 read for every entry on the second try?
--
Duy
On Wednesday 04 of December 2013 08:07:23 Duy Nguyen wrote:
On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast [off-list ref] wrote:
quoted
Paweł Sikora [off-list ref] writes:
Umm, there's a gem here that the thread missed so far:
quoted
my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git
version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
^^^^^^^^^
There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
res = sequencer_pick_revisions(&opts);
int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
[...]
return pick_commits(todo_list, opts);
}
static int pick_commits(struct commit_list *todo_list, struct replay_opts
*opts) {
[...]
read_and_refresh_cache(opts);
I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.
That's something to optimize, but it's single commit picking,
sequencer_pick_revisions() should call single_pick() instead of
pick_commits().
The read+close on the whole checkout looks like there's problem with
refresh operation and git decides to read up and verify sha-1 by
content. Pawel, if you run "strace git update-index --refresh" twice,
does it still show 1 stat + 1 read for every entry on the second try?
the 'git update-index --refresh' runs quickly and strace shows only lstat()
on every file. i see no massive open/read actions in this case.
$ strace -o strace-try1.log git update-index --refresh
hmdb: needs update
$ strace -o strace-try2.log git update-index --refresh
hmdb: needs update
$ grep -c lstat strace-try1.log
33793
$ grep -c lstat strace-try2.log
33793
--
gpg key fingerprint = 60B4 9886 AD53 EB3E 88BB 1EB5 C52E D01B 683B 9411