[FFmpeg-cvslog] r12593 - trunk/libavcodec/ac3dec.c

[Måns Rullgård]

Justin Ruggles <justinruggles at bellsouth.net> writes:

> Uoti Urpala wrote:
>> On Tue, 2008-03-25 at 19:38 -0400, Justin Ruggles wrote:
>>> jbr wrote:
>>>> @@ -191,6 +194,7 @@ typedef struct {
>>>>      GetBitContext gbc;                      ///< bitstream reader
>>>>      AVRandomState dith_state;               ///< for dither generation
>>>>      AVCodecContext *avctx;                  ///< parent context
>>>> +    uint8_t input_buffer[AC3_MAX_FRAME_SIZE];   ///< temp buffer to prevent overread
>>>>  } AC3DecodeContext;
>>> Right after I applied this, it occurred to me that it might be better to
>>> allocate this with av_malloc() at decoder init depending on
>>> error_resiliance.  Does that sound like a good idea?
>> 
>> I haven't looked at the specific code in this case, but generally moving
>> a commonly used buffer out of a context struct could hurt performance.
>> The compiler must either generate extra indirection through the struct
>> or reserve another register to keep the location of the buffer. OTOH if
>> time is mostly spent elsewhere, or if accesses to be buffer are not
>> interleaved with code which would also need to access the struct, then
>> it might not matter.
>
> Thanks Uoti. This is definitely a commonly used buffer, so maybe it is
> not a big enough trade-off just to reduce memory footprint when running
> with zero error_resilience.  I will test the speed, but if what you say
> is true, it will probably be slower.

On most systems, the extra allocation won't matter (much), since
physical pages are allocated only when written to.

-- 
M?ns Rullg?rd
mans at mansr.com