[MPlayer-dev-eng] speed of link strategies

[Michael Niedermayer]

On Sun, Jul 06, 2008 at 04:06:56PM +0200, Diego Biurrun wrote:
> On Thu, Jun 19, 2008 at 01:46:37PM +0200, Michael Niedermayer wrote:
> > On Thu, Jun 19, 2008 at 11:29:34AM +0200, Diego Biurrun wrote:
> > > 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
> 
> Your example was compiling multiple times.  The disk cache will kick in
> this case and the new system will link just as quickly.  It's not
> important if a single link takes 8s longer every once in a while.
> That's not a drain on anybody's time.

As i said already developers run tests between their compiles, they do
not just go and eat pizza. Thats the whole point of compiling
you change something, compile and test. If you arent planning to run
mplayer and test / use it for something, compiling has only limited sense.
"Ahh i didnt forget any ; who cares if it works ..."

If i change something in h264.c i check the change against the whole
h264-conformance streams, these are accoring to du 12GB. This flushes the
disk cache completely!
And while i wouldnt mind if the actual test takes 10sec extra, what takes
extra (if it where mplayer and not ffmpeg with which i run these tests)
is the next recompile. Iam not waiting for the test to finish but do
something else. I do wait for a recompile to finish
so i dont realize 10min later that the tests didnt even start.


> 
> > > 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 ...
> 
> It's the only x86 machine I can run benchmarks on.
> 
> > > 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.
> 
> The principle goal is correctness, the secondary goal is simplicity,
> performance comes third.
> 
> Correctness may not be sacrificed for speed or simplicity, ever.
> Simplicity can be exchanged for performance if the tradeoff is
> acceptable.
> 
> Per-directory linking is not a useful feature within MPlayer, it is a
> pure speed hack.  The performance benefit is very doubtful and it would
> come at the expense of considerable complication.  Thus I'm opposed to
> it.

you are root, no point to argue ...


> 
> Diego
> 
> P.S.: Has anybody tried Gold, the new GNU ELF linker?  It is said to be
> considerably faster...

As the current situation is limited by IO speed a different linker will
not solve this

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20080731/12a60590/attachment.pgp>