On Sun, Dec 06, 2015 at 05:43:45PM +0100, Andreas Krey wrote: > On Fri, 04 Dec 2015 15:31:03 +0000, John Keeping wrote: > ... > > I'm pretty sure that you're right and the cherry-pick analysis is where > > the time is spent. > > But I'm pretty surprised as to the amount of CPU time that goes there. > > I'm now rebasing a single commit with a single blank line added, > and for 3000 new commits to rebase over (with 64 MByte of git log - > for them) it takes twelve minutes, or about for commits per second, > and all user CPU, no I/O. It's pretty linear in number of commits, too. You're computing the patch against the parent for each of those 3000 commits (to get a hash of it to compare against the single hash on the other side). Twelve minutes sounds long, but if you have a really gigantic tree, it might not be unreasonable. You can also try compiling with "make XDL_FAST_HASH=" (i.e., setting that option to the empty string). Last year I found there were some pretty suboptimal corner cases, and you may be hitting one (we should probably turn that option off by default; I got stuck on trying to find a hash that would perform faster and never followed up[1]. I doubt that is your problem, but it's possible). -Peff [1] http://thread.gmane.org/gmane.comp.version-control.git/261638 -- 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