[Ffmpeg-devel] Bindings benchmark on visibility patch
Fri Sep 22 23:07:18 CEST 2006
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.
mru at inprovide.com
More information about the ffmpeg-devel