[FFmpeg-cvslog] random thoughts about refactoring (was: Re: r20938 - trunk/libavcodec/h263.c)

[Jason Garrett-Glaser]

> That seems to depend on CPU and situation, gcc making poor inlining choices
> and overflowing the available caches is not exactly the codes fault ...

Inlining effects are hardly a significant reason that the H.264 decoder is slow.

CoreAVC doesn't do anything particularly smart with inlining--if
anything, it makes far worse decisions than ffmpeg does--and yet it's
a lot faster, even when compiled with GCC, which it was never
optimized for.

> did i?
> i think i tend to insist on well split patches and on benchmarks on
> the individual parts. That is to weed out changes that worsen things

The problem that this creates IMO is that it forces a gradient-descent
search process in terms of optimizing code.  Sometimes one has to make
things slower before they can get faster, much like one has to "jump"
a hill in order to find the global minimum of a function.  One could
argue that the developer should continue optimizing until he can get
over the hill in his local tree, and then commit it as one big patch,
but people are often unwilling to work on large changes when they
aren't sure that they will even be accepted when they're done.

This is exacerbated by the fact that optimizing h264.c significantly
will require a *rearchitecture*: something that involves jumping a
very, very large hill.

Dark Shikari