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

[Michael Niedermayer]

On Tue, Jan 29, 2008 at 07:09:39PM +0100, Zdenek Kabelac wrote:
> 2008/1/12, Diego 'Flameeyes' Petten? <flameeyes at gmail.com>:
> > Roman Shaposhnik <rvs at sun.com> writes:
> >
> > >   Sorry for coming into this discussion a bit late, but are we talking
> > > about getting rid of all the static tables? DV codec uses quite a few
> > > of those -- that's why I'm interested.
> >
> > Actually I was proposing the opposite: have an opt-in way to remove the
> > runtime-initialised tables and replace them with buildtime-generated
> > static constant tables.
> >
> 
> There used to be allocation for static tables at runtime on the heap -
> I'm not sure why they have disappeared, 

Because, it
1. should have never been there in the first place
2. is completely unneeded (there are much cleaner and robust solutions)
3. doesnt work (it would need a mutex which we cant give it because its
   not portable)


> but I think increasing the
> library size for a megabyte is IMHO bad idea - at runtime the user
> will hardly use few codecs  at same time and the price of binary
> distribution of such monster hardly compressible binary tables vie net
> will ever hardly justify few ms you spend via runtime initialization.
> 
> All I would like to see is moving static tables to static pointer
> which would be initialized at the codec's first initialization and
> released when library is being freed. This is actually far more space
> saving than your proposal :)

This by far is the worst possible way by which one can allocate static
storeage.

If one uses 
static table[1234];
and initalizes it during init. Then this means small binary, and only
wasted memory if the table is initalized. Though it is duplicated for
each process which initalized it.

If one uses
static table[1234]= {1,2,5,6,7,0,0,1,2, 
Then this means large binary, and some always wasted memory but it is
shared between processes.

If one uses
static *table;
and malloc() and initialization during init. Then this is identical to the
first except that it causes a memleak on library unload on at least some OSs.

What you suggest is the 3rd variant with a workaround to its memleak
requireing thread synchronization.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080130/c7ca0380/attachment.pgp>