[Ffmpeg-devel] Bindings benchmark on visibility patch

Roman Shaposhnick rvs
Fri Sep 22 21:16:55 CEST 2006


On Fri, Sep 22, 2006 at 09:00:40PM +0200, Diego 'Flameeyes' Petten?
wrote:
> So, as people seems to want some concrete results produced by the
visibility
> patches I'm working on, I drafted up a parser for the
LD_DEBUG=bindings
> output, and counted the results (I'll make the script available in the
next
> days, give me time to make it something les specific than what I've
hacked up
> in 30 minutes of ruby hacking today).
>
> The output comes out of a xine-ui playing an AVI with ISO MPEG-4 video
stream,
> and MP3 audio stream (both decoded with FFmpeg plugin). xine-lib CVS
HEAD
> with visibility enabled in that, too (and external FFmpeg from SVN of
> course).
>
> Without visibility patch:
>
> libavcodec required 625 symbols (591 in itself)
> libavutil required 10 symbols (3 in itself)
> libpostproc required 9 symbols (none in itself)
>
> libavcodec resolved 702 symbols (591 from itself)
> libavutil resolved 13 symbols (3 from itself)
> libpostproc resolved 3 symbols (none from itself)
>
> -rwxr-xr-x 1 root root 2605648 22 set 19:32 /usr/lib/libavcodec.so
> -rwxr-xr-x 1 root root  438528 22 set 19:32 /usr/lib/libavformat.so
> -rwxr-xr-x 1 root root   17576 22 set 19:32 /usr/lib/libavutil.so
> -rwxr-xr-x 1 root root   32368 22 set 19:32 /usr/lib/libpostproc.so
>
> With visibility patch:
>
> libavcodec required 105 symbols (71 in itself)
> libavutil required 7 symbols (none in itself)
> libpostproc required 10 symbols (none in itself)
>
> libavcodec resolved 182 symbols (71 from itself)
> libavutil resolved 10 symbols (none from itself)
> libpostproc resolved 5 symbols (none from itself)

  I'm sorry but these are just numbers. They don't mean a whole
lot to me as long as you're not telling us what kind of
a benefit there is in having fewer symbols being resolved. I do
mean real benefit not just a theoritical point of having fewer
is better king of a thing.

> It *is* a good improvement in the amount of bindings required, and
please
> consider that xine does not use libavformat and I tried only with
*one* video
> per time; the advantage increase when you play more videos of
different
> formats.

  I'm sorry but I have a hard time deciphering this. Could you, please,
at least post benchmarks #s of some kind ?

> The size difference is minimal, but consider that I built it with -Os
on
> itself, and that this isn't C++ where the visibility improves
drastically the
> size of DSOs.

  Now, C++ is a whole different ball of wax and from this short
snippet it is absolutely unclear how ffmpeg project would benefit
from anything that has to do with C++. It is even unclear what's
there for us to interact with on a C++ side that needs fixing.

Thanks,
Roman.






More information about the ffmpeg-devel mailing list