[vorbis-dev] BeOS on PPC compile, thread question.

[Monty]

> Maybe I am missing something obvious, but if alloca() is simply allocating
> from the stack, why not just replace these with stack buffers? For example:
> 
> void function1(void)
> {
> 	/* Define a buffer of max size, aligned to int, needed from the
> stack. */
> 	int buf[256];
> 
> 	function2(buf);
> }

Because you can't do 'alloca[non_static_var]', and many aspects of
vorbis aren't bounded to small numbers.  Ie, you encourage lots of
static buffer errors.

> I'm sure people will answer "because you will waste stack space if you don't
> need the max size and perhaps blow your stack". 

No, you'll cause *lots* of cache pressure as things are scattererd a
half meg apart on the stack.

> I don't see that argument
> holding up, because if you had a worst case vorbis stream come in, it would
> still blow up with alloca() if it had to use larger allocations. 

More like 'be very slow'.  Why be very slow 100% of the time instead
of just in that 1 out of 10,000 streams?

> Another idea is to pre-allocate a number of buffers of a large enough size
> when your Vorbis_init() (not sure what the proper name is) type function is
> done, then just re-use those each time to avoid the continual malloc/free.

This results in a 30+M footprint for decoding even very simple things.

> P.S. - I throw my 2 cents in that Vorbis shouldn't use Malloc/Free(), but
> instead ask for  Malloc/Free() function pointers. These may be common in
> desktop computing but they are absolutely shunned in some applications (e.g.
> game consoles).

_ogg_malloc, etc, are defines in os_types.h now (a specific concession
to folks who have made the console argument in the past).  It's not
like the requirement of a different malloc would suddenly be a
surprise at runtime...

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.