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

[Diego Biurrun]

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      4.7s   13.8s
mencoder     3.2s   10.4s
 
r26339:
mplayer      4.0s    5.2s
mencoder     3.0s    6.1s
libmpcodecs  0.14s   0.6s
libmpdemux   0.07s   0.6s
libavcodec   0.34s   2.7s

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.

The old system links slightly faster (less than 1s) when recompiling
after just one changed file.  However, recursive make overhead cancels
that advantage.

The benchmarks are not completely accurate since the trees are not
identical.

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.  Adding complexity to the build
system to make up for that 1s is not worth any trouble.


For comparison: HEAD builds in 36m41s, while r26339 builds in 36m25s on
this machine.  HEAD generates dependencies in 3m30s, r26339 in 3m05s.
HEAD has some new files that could account for the slight slowdown.

Diego