Re: Rebase performance

From: Christian Couder <christian.couder@gmail.com>
Date: Feb 26, 2016, 18:15 UTC
Message-ID: <CAP8UFD0_+8cQvBHvrEe16DEa6F-4KZtJGKNqiRn_fMgfQqX_cg@mail.gmail.com>
In-Reply-To: <CACsJy8AUbLhfkeanQa101mygt1u_SxgbVAGc=USC79n9iR4R3w@mail.gmail.com>

On Thu, Feb 25, 2016 at 10:42 AM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 16 quoted lines

> On Thu, Feb 25, 2016 at 7:50 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
>> <christian.couder@gmail.com> wrote:
>>> Another possibility would be to libify the "git apply" functionality
>>> and then to use the libified "git apply" in run_apply() instead of
>>> launching a separate "git apply" process. One benefit from this is
>>> that we could probably get rid of the read_cache_from() call at the
>>> end of run_apply() and this would likely further speed up things. Also
>>> avoiding to launch separate processes might be a win especially on
>>> Windows.
>>
>> The amount of global variables in apply.c is just scary. Libification
>> will need some cleanup first (i'm not against it though). Out of
>> curiosity, how long does it take to do "git update-index <one modified
>> path>" on this repo? That would cover read_cache_from() and
>> write_cache().

Sure I get:

$ time git update-index <README

real 0m0.079s user 0m0.057s sys 0m0.022s

>> While you're measuring, maybe sprinkle some
>> trace_performance() in apply.c:apply_patch() to get an idea where time
>> is most spent in?

Each call to read_cache() takes around 0.07 seconds and each call to check_patch_list() takes around 0.045 seconds, the rest of apply_patch() is not significant.

> I did some experiment.

Thanks for those experiments. They are very interesting!

Show 16 quoted lines

> The calls from am are basically
>
> for i in $PATCHES; do git apply --cached $i; git commit; done
>
> and we can approximate the libification version of that with
>
> git apply --cached $PATCHES
>
> (I hacked git-apply to do write-tree after each patch, close enough to
> git-commit).
>
> I tried it on my shallow-deepen series, 26 patches. The "for; do
> git-apply;done" command took 0m0.482s (real's time), taskset does not
> affect much for me, while the "libification" took just  0m0.105s.
> That's a very impressive number to aim for, and git.git is a small
> repo.

Yeah, from my tests it also looks like there is a lot that could be gained from the libification.

Thanks, Christian.