Re: [PATCH] Show binary file size change in diff --stat

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

 



Hi,

On Wed, 4 Apr 2007, Linus Torvalds wrote:

> On Wed, 4 Apr 2007, Johannes Schindelin wrote:
> > 
> > The subtle difference: your approach is _expensive_ in terms of CPU time, 
> > while the byte change approach is _dirt cheap_.
> 
> Well, you could do a combination (still dirt cheap):
>  - show the size before/after (and yes, new/delete should be separate from 
>    "zero size before/after")
>  - show the size of the binary patch.

... and by this (size of binary patch) you mean the deltified object?

In general, we do not have the binary patch. And the generation of that 
binary patch is what I was referring to being expensive.

Remember, most binary files are way larger than the average source code 
files we have, since it is much, much easier to generate binary data than 
to write meaningful code. Therefore, the binary patch generation has to 
look at much larger pieces to begin with, which translates into CPU time.

Having said that, I have to admit that I don't have numbers backing this 
reasoning up. So, if somebody comes up with numbers contradicting my 
theory, I will gladly change my mind.

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]