On Thu, Feb 25, 2016 at 7:50 AM, Duy Nguyen <pclo...@gmail.com> wrote: > On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder > <christian.cou...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
