[Ffmpeg-devel] Bindings benchmark on visibility patch

[Michael Niedermayer]

Hi

On Fri, Sep 22, 2006 at 09:24:20PM +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?
> >
> > 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.

well use a short video with 1 frame, and if xine is too slow try some more
primitive player (ffmpeg or ffplay maybe)

anyway if the speed gain is unmeassureable then id say that "speed gain"
should be droped from the arguments

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is