[MPlayer-dev-eng] speed of link strategies (was: Re: [RFC] Makefile copyrights)

[Michael Niedermayer]

On Thu, Jun 19, 2008 at 11:29:34AM +0200, Diego Biurrun wrote:
> On Wed, Jun 18, 2008 at 07:52:56PM +0200, Michael Niedermayer wrote:
> > On Wed, Jun 18, 2008 at 04:27:49PM +0200, Diego Biurrun wrote:
> > > On Wed, Jun 18, 2008 at 03:44:18PM +0200, Michael Niedermayer wrote:
> > > > On Wed, Jun 18, 2008 at 02:31:34PM +0200, Diego Biurrun wrote:
> > > > > On Wed, Jun 18, 2008 at 02:56:37AM +0200, Michael Niedermayer wrote:
> > > > > > 
> > > > > > Besides, "HEAD with dependency generation disabled"? so you compare the
> > > > > > unchanged old build system against the new + some hacks to make it faster?
> > > > > 
> > > > > I am comparing apples to apples.  Your first claim was that link times
> > > > > would increase with the new system.  This is false.
> > > > 
> > > > I was speaking about the case with a changed file and not everything in the
> > > > cache. Collecting many small .o files takes longer than few big .a.
> > > > It may very well be that the old build system did other time consuming things.
> > > > I was only considering the current build system with per libmp* .a vs the
> > > > single big linking at the end.
> > > 
> > > You are wrong.  I ran benchmarks for the very case you are describing.
> > 
> > You did not run benchmarks for the actual link commands, ccache disabled,
> > 1 file changed and a fluhed cache.
> > You run benchmarks on current (+hack) vs. old make. When the hack was removed
> > old was already faster ...
> 
> Old was slightly faster because it did less things.
> 
> Here are benchmarks for the final link commands and the subdirectory
> link commands.  The first number is the "stabilized" number I get after
> rerunning the command multiple times, the second value was obtained
> after running some long grep command through my sources directory to
> flush the disk cache.
> 
> HEAD:
> mplayer      [...]   13.8s
> mencoder     [...]   10.4s
>  
> r26339:
> mplayer      [...]    5.2s
> mencoder     [...]    6.1s

Thank you for the benchmarks, these numbers are more belivable.


[...]

> 
> Given that there are a total of 25 subdirectories to link, total link
> times should have diminished with the new system when running a complete
> build from a cold cache.

I dont really care if a full build takes 36m41s or 36m25s. I do care if
each rebuild after testing takes 13.8s instead of 5.2s


[...]
> The conclusion seems to be clear: Total link times have been reduced by
> the flat build system.  Rebuild link times are within 1s of the old
> system on a very outdated machine.  

very outdated machine with RAID array ...
besides you are forgetting the most important values in your benchmark above


> Adding complexity to the build
> system to make up for that 1s is not worth any trouble.

Maybe not, but making up for that 50% speedloss might be. But then goals
change, features and performance may not be amongth them anymore.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080619/b623f10b/attachment.pgp>