Re: Rebase performance

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 25, 2016, 09:42 UTC
Message-ID: <CACsJy8AUbLhfkeanQa101mygt1u_SxgbVAGc=USC79n9iR4R3w@mail.gmail.com>
In-Reply-To: <CACsJy8DZOv2Z2hiUmRKHr_GCjsyVz9kQEE8a1F=h6Ku0Dr9g_w@mail.gmail.com>

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

Show 17 quoted lines

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

I did some experiment. 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.

-- 
Duy