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

Aurelien Jacobs aurel
Wed Mar 5 11:20:34 CET 2008


On Wed, 05 Mar 2008 08:25:51 +0200
Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Wed, 2008-03-05 at 01:04 -0500, Rich Felker wrote:
> > On Wed, Mar 05, 2008 at 07:32:07AM +0200, Uoti Urpala wrote:
> > > On Tue, 2008-03-04 at 23:51 -0500, Rich Felker wrote:
> > > > Splitting dsputil.c and motion_est.c would be a major improvement in
> > > > compilability. These files are waaaaaay too big and gcc stupidity
> > > > results in very slow and memory-intensive compiling, probably due to
> > > > useless searches for global optimizations or something.
> > > 
> > > In the case of motion_est.c I'd blame programmer stupidity more than
> > > compiler stupidity. It has big av_always_inline functions and macros
> > > using them which are then used lots of times. The code could be written
> > > more efficiently. (That's the same issue I mentioned earlier when
> > > discussing object sizes.)
> > 
> > Patch welcome.</michaelni>
> 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-January/041456.html
> 
> Btw changing "av_always_inline int cmp" to "av_noinline int cmp" and
> comparing object sizes before and after should give you some idea of the
> amount of repeating code in that file.

This indeed makes a huge difference (gcc-4.1 x86).

with av_always_inline:
   text    data     bss     dec     hex filename
 484960       0       0  484960   76660 libavcodec/motion_est.o

with av_noinline:
   text    data     bss     dec     hex filename
 140566       0       0  140566   22516 libavcodec/motion_est.o

Now, I don't know exactly what to benchmark to see if it makes
a big difference speedwise.

Aurel




More information about the ffmpeg-devel mailing list