[Ffmpeg-devel] Bindings benchmark on visibility patch

[Roman Shaposhnick]

On Fri, 2006-09-22 at 23:20 +0200, Diego 'Flameeyes' Petten? wrote:
> 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.

  I'm actually pretty curious to see the data even if its something
along the lines of LD_BIND_NOW. At lest that will give us an
understanding of a worst case scenario.

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

  If 2% speedup of dlopen() is all there is -- I would vote strongly
against this patch.

Thanks,
Roman.