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

[Michael Niedermayer]

On Tue, May 04, 2010 at 10:48:02PM +0000, Loren Merritt wrote:
> 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.
> Otoh, there are systems with much slower malloc (OSX?).
>
> --Loren Merritt

>  bitstream.c |   11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 3bc1250b709639dccc4b8f6fc5c684983c9c5990  vlc_malloc.diff
> diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c

no objections, if people prefer malloc() over var-arrays

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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-cvslog/attachments/20100505/e0c4d808/attachment.pgp>