From: "Paweł Sikora" <pawel.sikora@agmk.net>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Thomas Rast <tr@thomasrast.ch>,
Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: slow git-cherry-pick.
Date: Wed, 04 Dec 2013 13:46:43 +0100 [thread overview]
Message-ID: <1827709.rD7YulLKCL@localhost.localdomain> (raw)
In-Reply-To: <CACsJy8Be2USmGA--FLT3LERTde327Ue65CCjoLHi5SzNzUX1dw@mail.gmail.com>
On Wednesday 04 of December 2013 08:07:23 Duy Nguyen wrote:
> On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast <tr@thomasrast.ch> wrote:
> > Paweł Sikora <pawel.sikora@agmk.net> 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.
>
> 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
prev parent reply other threads:[~2013-12-04 12:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-24 10:45 slow git-cherry-pick Paweł Sikora
2013-11-24 12:47 ` Duy Nguyen
2013-11-24 12:48 ` Duy Nguyen
2013-11-24 19:17 ` Paweł Sikora
2013-11-25 17:26 ` Junio C Hamano
2013-12-03 19:31 ` Paweł Sikora
2013-12-03 20:13 ` Thomas Rast
2013-12-04 1:07 ` Duy Nguyen
2013-12-04 12:46 ` Paweł Sikora [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1827709.rD7YulLKCL@localhost.localdomain \
--to=pawel.sikora@agmk.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=tr@thomasrast.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.