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

[Uoti Urpala]

On Tue, 2010-05-04 at 23:59 +0100, M?ns Rullg?rd wrote:
> Loren Merritt <lorenm at u.washington.edu> writes:
> >>> 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.

You can't completely rule out the performance impact of a repeated
malloc with any simple test. It can depend on usage patterns. There's
also the effect on memory fragmentation. Even if the code frees the
memory without any other allocation in between that may not hold
globally due to other threads. In some cases cache effects may matter
(malloc is almost certainly worse for cache than stack).

> > 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.

Is there a reason why they should more "blame themselves" than people
running systems that have problems with the arrays on stack?

In general malloc will perform worse and result in more complex and
fragile code. Even if you add explicit sanity/safety checks for all
stack arrays the result will be simpler and more robust than with
malloc.