Re: Rebase performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
<christian.couder@xxxxxxxxx> 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? 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]