On Thu, Feb 25, 2016 at 10:42 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Thu, Feb 25, 2016 at 7:50 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> 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(). 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! > 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. -- 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