Re: Rebase performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 26, 2016 at 7:45 AM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
> Hi Matthieu,
>
> On Thu, 25 Feb 2016, Matthieu Moy wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]