[FFmpeg-devel] [PATCH] move ff_emulated_edge_mc() to dsputil

[Uoti Urpala]

On Wed, 2008-03-05 at 12:28 +0100, Michael Niedermayer wrote:
> no, there were 2 suggestions from uoti

> 1.---
> It would be possible to trim the code size by hundreds of kB too.
> Currently gcc 4.3 generates a 576268 bytes for motion_est.o alone on
> x86. I think it would be possible to shrink that by at least half
> without much speed loss (yes the cmp function can be optimized
> differently depending on parameters, but I very much doubt it's
> justified to have 136 different versions of it).

That's not a specific suggestion in the sense of a patch, more like
pointing out an area that could be significantly improved. Removing most
of the 136 copies of the function should be possible; however just
making the function non-inline is probably not the optimal way to do
that. At least it could be split into a couple of different versions
depending on known flag values. Even the simple non-inline version could
be faster in at least some cases though as it's so much smaller - it's
hard to estimate the effect without testing.

> 2.---
> On Thu, 2008-01-31 at 17:09 +0100, Michael Niedermayer wrote:
> > A patch which makes it smaller at the same or better speed
> > or one which makes it faster at the same size, is welcome.
> 
> I don't currently use FFmpeg for encoding and do not have problems with
> binary size so I have little motivation to work on this. However those
> who are interested could test the attached example patch and see whether
> it has any benchmark effect (I don't have a ready setup for
> benchmarking). It reduces binary size by about 10kB on x86/gcc-4.3.
> -----


> No benchmarks were provided, even though it has been requested multiple
> times, and uoti indicated that the main suggestion caused a slowdown.
> So i droped all related patches in the sense that i would not
> bother any further until someone did provide benchmarks. Noone provided
> any so far ...

For the reasons explained in the quoted post above I have little
motivation to do much work on optimization or benchmarking of
motion_est. I wouldn't expect the patch I posted to cause slowdown. Just
making the cmp function non-inline might or might not cause slowdown
(could depend on the use case too). Even if that does I believe it's
possible to write the code in a smarter way that removes most of the
repeated code without slowdown (like the example patch does for a small
chunk of code).