[FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.

[Reimar Döffinger]

On Sun, Mar 13, 2016 at 01:27:52PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Mar 13, 2016 at 1:21 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> >> > I don't understand the waste; the double init anyway needs to be done,
> >> > all tables are derived from it. This dates to an approach I did in
> >> > commit:  07a11ebcab9b31e9fc784029e5d24e6fbf486ff3.
> >>
> >> The waste is in writing to the table that will never be used.
> >> As long as it is left as 0, it will not use memory, as soon
> >> as you touch it it uses up memory.
> >> But see my patch, if people think it's better it can be added.
> >
> > And looking at that commit, I actually realize now that the
> > cbrt_tab_dbl will also permanently waste 64 kB of memory despite
> > never being used again.
> > Using malloc/free for it would potentially be better (though
> > in general I have some doubts about the wisdom of optimizing
> > for initialization time at the detriment of runtime performance
> > or memory usage).
> 
> --enable-hardcoded-tables partially does that; it increases memory
> usage as tables are burnt into the library at some gains for
> initialization time.

No, exactly not. It increases disk usage, but it decreases memory
usage.
Tables are not loaded just because they are in the binary, not
when they are in .rodata.
If you are really lucky, even when the cbrt tables are used but only
a small part of them, with --enable-hardcoded-tables you'd not
even necessarily end up with all of them in RAM (admittedly
you can also see that as a disadvantage: the chances that
you end up with a page fault in the middle of decoding when
you don't really want it is there, too).
Gaining initialization time is absolutely not the point of
that option, it doesn't make sense and I have no idea
how that myth came to be (it may admittedly be true
in some cases, but it's not the point or very relevant).
Just for AAC CBRT tables (which are small in comparison),
hardcoded tables saves 128 kB of RAM/swap once you no longer
use the AAC codecs compared to your patch (64 kB for the
double table + 2*32kB for the final tables + possibly
a little bit from not needing the initialization code).
Of course 128 kB less in swap space vs. 64 kB more in the
binary/main storage is not really very useful in most cases,
but I don't think one can argue it is worse.