Re: slow git-cherry-pick.
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Dec 4, 2013, 01:07 UTC
- Message-ID
- <CACsJy8Be2USmGA--FLT3LERTde327Ue65CCjoLHi5SzNzUX1dw@mail.gmail.com>
- In-Reply-To
- <87fvq9n154.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098>
On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast <tr@thomasrast.ch> wrote:
Show 34 quoted lines
> 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?
-- Duy