Re: Rebase performance

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 25, 2016, 00:50 UTC
Message-ID: <CACsJy8DZOv2Z2hiUmRKHr_GCjsyVz9kQEE8a1F=h6Ku0Dr9g_w@mail.gmail.com>
In-Reply-To: <CAP8UFD0p1kvk2B0kkc-M9dm+H-Bmam=OrE99VwQx=KCETFEjcw@mail.gmail.com>

On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder <christian.couder@gmail.com> wrote:

Show 7 quoted lines

> 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? This is a big guess, but if we spend more time parsing/validating the patch than applying, then that part could be parallelized, we only need to apply patches in sequence.

-- 
Duy