[FFmpeg-devel] [RFC] remove table_4_3_value with CONFIG_SMALL

[Reimar Döffinger]

On Thu, Oct 15, 2009 at 02:48:04PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Thu, Oct 15, 2009 at 11:45:31AM +0100, M?ns Rullg?rd wrote:
> >> You're forgetting all the RAM-constrained systems we don't test on.
> >
> > Well, do you have any hard information on? I only seem to remember that
> > e.g. rockbox used hardcoded-tables, but not small.
> 
> My Blackfin struggles even with CONFIG_SMALL, which is why it isn't
> yet on FATE.

Ok, if you have hints for specific issues I wouldn't mind looking into
it, I am sure there are cases where CONFIG_SMALL can be used in a less
disputable way than here.

> >> It is at least as nonsensical to have CONFIG_SMALL assume a blazingly
> >> fast FPU is available.
> >
> > Yes, to a degree (though that might need further investigation with
> > someone who actually uses --enable-small), though you could just as
> > well say that those device with little memory are likely to have
> > even slower CPUs, thus (almost) all those CONFIG_SMALL optimizations
> > are nonsensical (yes, it is an exaggeration, but maybe you get the
> > idea).
> 
> No, I do not get the idea.  Making the code orders of magnitude slower
> to save a few kB is not acceptable.  Period.

Probably.
But you are misrepresent this from the numbers I have (I admit, I have no
FPU-less system to test on), it saves more than 100 kB while on
FPU-enabled devices slowing down the function by a factor for (so its
likely "orders of magnitude slower" on FPU-less), but that function is
only a small part of overall MP3 decoding.
I really don't think it's as black-and-white as you paint it, and that's
(almost) all I tried to say.