[Ffmpeg-devel] Bindings benchmark on visibility patch

[Diego 'Flameeyes' Pettenò]

On Friday 22 September 2006 21:16, Roman Shaposhnick wrote:
> 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)
>   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.
Every time a binding has to be resolved, the dynamic linker (ld.so) has to 
look up it in the loaded libraries, which requires iterating through the 
symbol tables. Less bindings to be resolved implies practical shorter times 
to load and to call functions the first time.

>   I'm sorry but I have a hard time deciphering this. Could you, please,
> at least post benchmarks #s of some kind ?
Well, they are benchmark values, I cannot really provide actual timing 
results, mostly because I know the current xine architecture will make them 
pretty pointless (there's a whole waste of time in it, I'm planning to fix it 
when I have time but it's not ready yet), not counting that it will also 
depend on the time required to actually play the video.

>   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.
You seem *very* confused on this to me.
What I was saying is just that hidden visibility does not have one of the many 
advantages when applied to C libraries: the drastic improvement in size.
This has not to be considered as a fault of the way -fvisibility=hidden is 
applied here, but rather as something that applies only on C++, so that you 
don't get mislead by the minimal size difference between the two to say "ah, 
the improvement is too small to be useful".

-- 
Diego "Flameeyes" Petten? - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060922/4863be02/attachment.pgp>