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

[Zdenek Kabelac]

2008/1/31, Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> Hello,
> On Thu, Jan 31, 2008 at 02:14:53PM +0100, Zdenek Kabelac wrote:
> > But there is always chance you will want to install the ffmpeg into
> > some limited sized eeprom/CD/distro and you want to save some memory
> > for other things - so while you could have a lot of dynamic memory -
> > you are limited by the ROM size....
>
> The tables in .bss solve that problem already though.

Well yes - on the 'modern' OS - but .bss are uninitialized section -
and I'm just fine with them (as I said already earlier)

>
> > It's probably not so easy to say which tables should be created for
> > the codec initialization - should it take less then 0.1ms on 400MHz
> > CPU :) though for me I would even support the idea to have the tables
> > created always when codec is opened/closed.
> > But it might be nice to have the build with 'static table' or
> > dynamicaly computed tables - I think there is already zillion of
> > defines thus this one extra wouldn't be so problematic - routines for
> > table generation could be held in one .c file - and added only when
> > such build is requested.
>
> I assume that you mean having the tables in the codec context. As said,
> I think that sometimes that might be preferable, but you seem to miss
> the biggest drawbacks: An application that decodes lots of streams will
> have these tables lots of times in memory, and maybe more importantly it
> means one additional pointer dereference for each access to the table,
> possibly even causing register spill in an innermost loop.
> And if the table is used in asm code, you might also need different code.

It depends on how do you create/implement it - you could of course
count the number of references to have the table just once in the
memory - you may even use shared-memory to share them across the
processes - though this isn't worth to implement...

I think the solution with empty static tables filled with the first
codec invocation its just the easiest solution (if the heap allocation
is seen as 'very' broken)...

My main intention in this thread is - that original author of the post
should avoid inclusion of all tables into the binary :) nothing more.

And if there would be a chance to switch couple of massive tables into
a runtime generated - it would be a nice benefit - but if the majority
of developers thinks oppositely - I've just expressed my view on
this... nothing more...

Zdenek