[Ffmpeg-devel] Bindings benchmark on visibility patch

[Måns Rullgård]

Diego 'Flameeyes' Petten? <flameeyes at gentoo.org> writes:

> On Friday 22 September 2006 23:03, Michael Niedermayer wrote:
>> well use a short video with 1 frame, and if xine is too slow try some more
>> primitive player (ffmpeg or ffplay maybe)
> I'll try to find it, but with a single frame most of the functions
> are unlikely to get called anyway. The problem is that with lazy
> bindings you get the binding time spread across the execution, and
> with dlopened plugins you're not hitting all the bindings when
> you're playing a single file.
>
>> anyway if the speed gain is unmeassureable then id say that "speed gain"
>> should be droped from the arguments
> It's load speed gain that interests me, to be honest. I can see the
> difference through callgrind's output, it's about a 2% gain on the
> dlopen() subcall. It's not much when compared to the snail slow
> loadtime of xine's framework, but it will likely be (I know there
> are other libraries that causes this problem, for once libmp4v2, and
> that their effect is probably larger, but FFmpeg is also summed in
> all this, and I considered it an easy task to start with).
>
> To put it plainly, the gain is there, it's not huge, it's not
> microscopic, it's just difficult to benchmark properly.

Is this a joke or something?  2% gained on a dlopen() call?  Do you
seriously believe we'll even consider ripping ffmpeg to bits to make a
dlopen() call 2% faster?  I don't care if dlopen() became 200%
faster.  If actual *encoding* isn't faster, there's no point.

-- 
M?ns Rullg?rd
mru at inprovide.com