[Ffmpeg-devel] Bindings benchmark on visibility patch

[Måns Rullgård]

Diego 'Flameeyes' Petten? <flameeyes at gentoo.org> writes:

> On Friday 22 September 2006 21:16, Roman Shaposhnick wrote:
>> On Fri, Sep 22, 2006 at 09:00:40PM +0200, Diego 'Flameeyes' Petten? wrote:
>> > 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.

Who cares if it takes 5ms or 20ms to start up?  When I talk about
benchmarks, I mean decoding/encoding performance.

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

What xine does is uninteresting.  Measure the time it takes for ffmpeg
to transcode a piece of video from one format to another, with and
without the visibility patches.  Be sure to use a sample takes at
least a minute to reduce the effect of startup overhead.

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

So far I haven't seen demonstrated any improvement whatsoever, drastic
or otherwise, to anything at all.  Adding all this mess only to make
use of an unnecessary compiler option is unacceptable.

-- 
M?ns Rullg?rd
mru at inprovide.com