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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 4, 2007, 16:59 UTC
Message-ID: <Pine.LNX.4.63.0704041856210.4045@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <Pine.LNX.4.64.0704040935350.6730@woody.linux-foundation.org>

Hi,

On Wed, 4 Apr 2007, Linus Torvalds wrote:

Show 9 quoted lines

> 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