[FFmpeg-cvslog] r22715 - trunk/libavcodec/bitstream.c

[Måns Rullgård]

Loren Merritt <lorenm at u.washington.edu> writes:

> On Tue, 4 May 2010, M?ns Rullg?rd wrote:
>
>> Loren Merritt <lorenm at u.washington.edu> writes:
>>
>>> On Sun, 2 May 2010, M?ns Rullg?rd wrote:
>>>
>>>> lorenm <subversion at mplayerhq.hu> writes:
>>>>
>>>>> @@ -258,6 +275,9 @@ int init_vlc_sparse(VLC *vlc, int nb_bit
>>>>>               const void *symbols, int symbols_wrap, int symbols_size,
>>>>>               int flags)
>>>>>  {
>>>>> +    VLCcode buf[nb_codes];
>>>>
>>>> Sorry for not noticing this earlier, but is there any way that
>>>> variable-length array could be removed?  Such beasts are made of pure
>>>> evil.  We should be slaying them, not helping them spread.
>>>
>>> a) malloc.
>>
>> Would this have any measurable impact on performance?  Is this
>> function ever called more than once per frame?
>
> No measurable difference in overall speed for ffvhuff, which has 3
> tables per frame.
> START_TIMER says that the malloc is 400 cycles on linux/x86_64, which
> should make it 0.01% of overall time, or less for large frames.

That settles it for me.

> Otoh, there are systems with much slower malloc (OSX?).

They can blame themselves.  If it's really important to someone,
linking ffmpeg with a different malloc is trivial.

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