[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