Hi Elijah, On Fri, 7 Jan 2022, Elijah Newren wrote: > On Fri, Jan 7, 2022 at 11:36 AM Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > ... > > Mind you, I did not even get to the point of analyzing things even more > > deeply. My partner in crime and I only got to comparing the `merge-ort` > > way to the libgit2-based way, trying to get them to compare as much > > apples-to-apples as possible [*1*], and we found that even the time to > > spawn the Git process (~1-3ms, with all overhead counted in) is _quite_ > > noticeable, at server-side scale. > > > > Of course, the `merge-ort` performance was _really_ nice when doing > > anything remotely complex, then `merge-ort` really blew the libgit2-based > > merge out of the water. But that's not the common case. The common case > > are merges that involve very few modified files, a single merge base, and > > they don't conflict. And those can be processed by the libgit2-based > > method within a fraction of the time it takes to even only so much as > > spawn `git` (libgit2-based merges can complete in less than a fifth > > millisecond, that's at most a fifth of the time it takes to merely run > > `git merge-tree`). > > Out of curiosity, are you only doing merges, or are you also > attempting server-side rebases in some fashion? One step after another. For now, I am focusing on merges. But yes, rebases are on my radar, too, and I am very grateful for the head-start you provided in `t/helper/test-fast-rebase.c` (and for the pun therein). Ciao, Dscho
