[Ffmpeg-devel] Bindings benchmark on visibility patch
Fri Sep 22 21:16:55 CEST 2006
On Fri, Sep 22, 2006 at 09:00:40PM +0200, Diego 'Flameeyes' Petten?
> So, as people seems to want some concrete results produced by the
> patches I'm working on, I drafted up a parser for the
> output, and counted the results (I'll make the script available in the
> days, give me time to make it something les specific than what I've
> in 30 minutes of ruby hacking today).
> The output comes out of a xine-ui playing an AVI with ISO MPEG-4 video
> and MP3 audio stream (both decoded with FFmpeg plugin). xine-lib CVS
> with visibility enabled in that, too (and external FFmpeg from SVN of
> 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
> consider that xine does not use libavformat and I tried only with
> per time; the advantage increase when you play more videos of
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
> itself, and that this isn't C++ where the visibility improves
> 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.
More information about the ffmpeg-devel