Hi, On Fri, Oct 21, 2011 at 1:23 AM, Jason Garrett-Glaser <[email protected]> wrote: > On Fri, Oct 21, 2011 at 12:13 AM, Ronald S. Bultje <[email protected]> wrote: >> This actually causes them to be inlined, leading to a significant >> speedup (1-1.5% in my measurements). > > Watch your binary size, last time I always_inlined all of hl_motion, I > ended up with like 300 kilobytes more code. I couldn't find a > satisfactory way to make gcc inline enough of it to be useful without > creating a mess.
The intention of the code is quite clearly to be inline, it was marked with inline after all, and there's all kind of constant function arguments in it. I'm currently just fixing it up to actually do that. If our intention is not to inline it any longer (which is fine with me, even at a slight performance penalty if it must), we need to identify which functions we no longer want to inline. Right now that whole place is a mess and 1.5% in overhead is a lot. E.g. we could create mc_dir/weighted_std_420/422/444_8/16bits (or a subset of these if we don't think they're all relevant, plus then the generic one), and then use an av_always_inline'ed mc_part that chooses which one to call. If we want to go further, we can choose to not inline mc_dir_part. Also these functions are so big, it may make sense to split out hl_motion and its callees into a separate file. Any takers? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
