[MPlayer-dev-eng] speed of link strategies

[Uoti Urpala]

On Thu, 2008-07-31 at 02:12 +0200, Michael Niedermayer wrote:
> 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:
> > > 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 ..."

Usually testing does does not involve so much data that it would empty
the disk cache.

> 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!

You actually play back 12 GB of video? How long does that take? Also how
long does compiling h264.c take?

> 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.

If you have such scripted long-running tests you could make the script
load the build tree back into disk cache after it finishes.