RetroSearch Browse

Fri Jan 19 01:41:21 CET 2007 · https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/027629.html

On Thu, 2007-01-18 at 00:31 +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 17, 2007 at 01:32:28PM -0800, Roman Shaposhnik wrote:
> > On Wed, 2007-01-17 at 20:46 +0100, michael wrote:
> > >  /**
> > > @@ -111,7 +98,11 @@
> > >          return -1;
> > >      while (buf_size > 0) {
> > >          int len = FFMIN(f->end - f->rptr, buf_size);
> > > -        func(dest, f->rptr, len);
> > > +        if(func) func(dest, f->rptr, len);
> > > +        else{
> > > +            memcpy(dest, f->rptr, len);
> > > +            dest = (uint8_t*)dest + len;
> > > +        }
> > >          f->rptr += len;
> > >          if (f->rptr >= f->end)
> > >              f->rptr = f->buffer;
> > 
> >   I'm just wondering whether this will make any noticeable
> > performance impact because of an extra call. Or am I splitting
> > hairs here ?
> 
> hmm the extra call av_fifo_read -> av_fifo_generic_read happens just if
> gcc doesnt inline the function

  Right. And it does. I've checked. I guess what I was really thinking
of was moving av_fifo_read's definition to the .h file in order to
let gcc do tailcall elimination instead of expanding the body and 
making fifo.o larger. But, of course, from the performance standpoint
having av_fifo_read() expanded makes a bit more sense.

> the extra if() also should disapear for av_fifo_read() if its inlined
> and the body of the while loop will be executed just once normally
> and rarely twice, but never more often then twice
> 
> do you know of any specific places in libav* where there are so many
> calls to av_fifo_*read() that this could matter?

  Nope. All I care about is av_fifo_peek() ;-)

Thanks,
Roman.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/027629.html below:

[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r7570 - trunk/libavutil/fifo.c