[Ffmpeg-devel] Bindings benchmark on visibility patch

[Roman Shaposhnick]

On Fri, 2006-09-22 at 21:24 +0200, Diego 'Flameeyes' Petten? wrote:
> On Friday 22 September 2006 21:16, Roman Shaposhnick wrote:
> > On Fri, Sep 22, 2006 at 09:00:40PM +0200, Diego 'Flameeyes' Petten?
> > > 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 know all of this (and some more because of the TLS efforts I've been
involved here at Sun). But I still can not convince myself that it buys
us much. The burden of proof is still on your side. I haven't seen use 
cases yet and I haven't seen real benchmarks yet. Once you provide the
two we can have a meaningful discussion around whether the intrusiveness
of your patch is worth it.  

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

  Well, since ffmpeg is *not* a C++ library all you're saying is that
your patch has one less advantage in our case, right ? If so, that is
educational but a bit irrelevant. And it gets us back to the actual
questions: what's there for ffmpeg in it.


Thanks,
Roman.