[MPlayer-dev-eng] [PATCH] Use posix_fadvise in stream_file if available
ranma at tdiedrich.de
Mon Nov 9 12:15:17 CET 2009
I removed the two posix_fadvise calls in open and seek, since for
both cases a delay is to be expected anyway, having fadvise just in
fill_buffer should be enough.
IO bound actions like stream copy or dumpstream are candidates for
negative effects due to extra syscall overhead, so:
dumpvideo with patch:
Run1: 1m37.205s real, 1m20.357s system, 0m2.746s user
Run2: 1m31.223s real, 1m19.923s system, 0m2.726s user
This one is actually CPU-bound on this system.
dumpvideo without patch:
Run1: 0m54.749s real, 0m7.221s system, 0m4.676s user
Run2: 0m55.752s real, 0m7.122s system, 0m4.811s user
So, the "don't call fadvise every time with the whole 1MB area" I
had in it at first was not premature.
Let's try a slightly modified patch that looks ahead PREFETCH_LEN
and uses max_len for the length...
(Still suboptimal, since max_len is usually 2048 and posix_fadv is
bound to use full pages internally...)
dumpvideo with modified patch:
Run1: 0m52.384s real, 0m7.364s system, 0m4.016s user
Run2: 0m53.041s real, 0m7.408s system, 0m3.986s user
IO-bound, slight speedup?
Much better, but needs the fadvise calls in open and seek added back
in. Let's try calling fadvise only occasionally instead.
dumpvideo with third patch:
Run1: 0m54.417s real, 0m11.211s system, 0m2.980s user
Run2: 0m51.495s real, 0m11.067s system, 0m2.914s user
Hmm, increased the amount spent in kernel, let's go back to the
previous version and add the fadvise calls in open and seek.
Run1: 0m53.896s real, 0m11.641s system, 0m3.220s user
Run2: 0m52.512s real, 0m11.658s system, 0m3.216s user
Ok, looks like the file I used for testing is one of those badly
muxed ones, the demuxer seeks a lot (would be nice if it could skip
audio completely for -dumpvideo) so quite a few overlapping fadvises
for the whole 1MB prefetch get called explaining the increased
Unfortunately a lot of Leopard-Raws files are broken that way...
Trying a properly mixed file:
Run1: 0m52.213s real, 0m4.361s system, 0m2.019s user
Run2: 0m51.481s real, 0m4.258s system, 0m2.093s user
Run1: 0m48.986s real, 0m4.970s system, 0m2.056s user
Run2: 0m48.376s real, 0m5.005s system, 0m1.975s user
Yep, that looks more reasonable.
Updated patch attached.
Tobias PGP: http://8ef7ddba.uguu.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1666 bytes
Desc: not available
More information about the MPlayer-dev-eng