Re: git-revert is a memory hog

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

 



On Wed, Jan 30, 2008 at 09:49:44AM +1100, Linus Torvalds wrote:

> But  the
> 
>         if (rename_limit <= 0 || rename_limit > 32767)
>                 rename_limit = 32767;
> 
> which is there purely to avoid overflow in 32-bit multiplication should 

Ah, right, that first conditional handles the overflow. Then what is the
second one doing? If they are both larger than the rename limit, then
won't there square by definition be larger than the square of the rename
limit? I.e., can't we just get rid of the second conditional?

> Or, better yet (which was what I was hoping for originally), we'd just 
> make the inexact rename detection be linear-size/time rather than O(m*n). 
> But those patches never really came together, so we do need to limit it 
> more aggressively.

I had trouble getting the memory usage to a reasonable level. The hash
tables were just getting enormous.

-Peff
-
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