On Fri, Feb 26, 2016 at 7:45 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Matthieu, > > On Thu, 25 Feb 2016, Matthieu Moy wrote: > >> Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: >> >> > At the risk of derailing this thread, a thing that would make rebase >> > even faster I think would be to change it so that instead of applying >> > a patch at a time to the working tree the whole operation takes place >> > on temporary trees & commits and then we'll eventually move the branch >> > pointer to that once it's finished. >> > >> > I.e. there's no reason for why a sequence of 1000 patches where a >> > FOO.txt is changed from "hi1", "hi2", "hi3", ... would be noticeably >> > slower than applying the same changes with git-fast-import. >> >> Also, not touching the worktree during rebase would have the advantage >> that if the final result doesn't change a file, we wouldn't need to >> touch this file at all, hence the next "make" (or whatever >> timestamp-using build system the user runs) would consider this file >> unchanged. > > We still have to write all blobs. So I would still expect this to be I/O > bound.
But if there is an IO bound process, the only way to make it faster is to reduce its IO, which was the proposal here? I agree that it probably is not enough to shift it from being IO bound to say CPU bounded. Thanks, Stefan > > Ciao, > Dscho -- 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
