On Sat, Sep 26, 2015 at 1:18 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Sat, Sep 26, 2015 at 6:48 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >> On Sat, Sep 26, 2015 at 12:26 PM, Henrik Gramner <hen...@gramner.com> wrote: >>> On Sat, Sep 26, 2015 at 6:10 PM, Ganesh Ajjanagadde <gajja...@mit.edu> >>> wrote: >>>> Have you compared with av_always_inline? >>> >>> No, other functions in that header used "inline", so I went with the >>> same for consistency. But I guess we could change those as well if >>> av_always_inline is preferable. >> >> Commit 06eb4f0885746b7e8a652d7b6026abf834e04b73 has a fairly detailed >> explanation of av_always_inline. Essentially the question is: do we >> trust the compiler to do the right thing here? In the worst case, the >> compiler will not inline it, in which case what is the performance >> penalty? >> My suspicion is that the loss is not that bad, and since there is no >> inline asm, the compiler in all likelihood won't need the >> av_always_inline. >> >> Thus either one should be ok (pick whichever you prefer), and so LGTM. > > The functions were not inline before, so there is no "penality", and only > gain. > For consistency, picking normal inline should be preferred here.
I meant penalty when comparing inline vs av_always_inline, and not current vs proposed patch. Anyway, patch is fine. > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
