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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).