Re: git-revert is a memory hog

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

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> This instead allocates and keeps only M records in core.  For
> each dst, we compute similarlity with all sources (so the number
> of similarity estimate computations we do is still N x M), but
> we keep the best src for each dst.  This is essentially to save
> memory drastically by giving up to come up with better pairing.
>
> I guess we could keep a handful best candidates per dst, instead
> of just one, to further improve on this approach, and such a
> change should be fairly straightforward.

An obvious side note to this patch is that if we are going to
limit us to only 1 source candidate per destination, we do not
even have to allocate.  We can just do similarity one-by-one for
each destination, and pair up with the best source as we go.

I did not code it that way, primarily because that would
permanently close the door to extend it back to keep multiple
candidates per dst, so that later ones that gets processed can
notice what happened to earlier ones.
-
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]

  Powered by Linux