[FFmpeg-devel] [RFC] Runtime-inited versus Hardcoded tables.

[Diego 'Flameeyes' Pettenò]

Mike Melanson <mike at multimedia.cx> writes:

> Is there some command line tool that you are running in order to audit
> the binaries for these sub-optimalities? If so, I might want to add it
> to the automated test suite.

Just for fun, before going to bed - damn fever - I decided to try this
command:

{objdump -t libavcodec/*.o | fgrep .bss | awk '{ print $5 }' | sed -e
's:^:0x:' -e 's:$: + :'; echo 0; } | irb

(irb is the ruby interpreter).

The result is 984113 here (x86-64), which means about 961KiB. This is
the amount of memory that every full-inited process using libavcodec
will use just to keep the tables (at least those initialised to zero and
declared directly in the code, rather than allocated in heap at
runtime).

(Actually this value is not including the 33K of PCM tables as I patched
that already).

If all the tables were hardcoded (with CONFIG_HARDCODED_TABLES), the
size of the compiled libavcodec will increase of about the same size,
but then the tables would be used just once rather than once per
process.

I think at this point the biggest problem on the long term would be to
actually regenerate the tables if the code used to ini them at runtime
is changed. I have an half-decent idea, but I need to check it out the
fesibility first:

Instead of adding the init code in foo.c and the hardcoded tables in
foo_data.h (added to SVN), we could move the runtime-generated tables in
foo_tables.c, with an #ifdef TABLEGEN for a function that actually
generates the table.
At build time, the Makefile could be compiling foo_tables.c in
foo-tablegen and then run it to generate foo_data.h.

The problem here would be mostly cross-compiling..

Comments?

-- 
Diego "Flameeyes" Petten?
http://farragut.flameeyes.is-a-geek.org/