Re: slow git-cherry-pick.

> 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?