[FFmpeg-devel] [PATCH 1/3] avutil: add staticpool
mfcc64 at gmail.com
Mon Jan 22 02:21:37 EET 2018
On Sun, Jan 21, 2018 at 7:11 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Sun, 21 Jan 2018 10:24:21 +0700
> Muhammad Faiz <mfcc64 at gmail.com> wrote:
>> > I don't trust the atomics use
>> > either, I'm don't want to have to debug that ever.
>> Of course, using atomics is more complicated that using mutex (with
>> benefits that it will be faster when properly used).
>> But it is not a valid reason to avoid using atomic because it is more
> Sure, but it also means it should be really be confined to cases where
> it _really_ helps with performance.
> Where is this a bottleneck at all?
Performance difference is noticeable with audio-only stuff.
Because audio processing is typically fast, malloc-free cycle of
AVFrame, AVBuffer, etc becomes bottlenecks.
> I also think that this really belongs into a malloc implementation
> instead. You might also want to try "alternative" malloc
> implementations like jemalloc.
jemalloc nicely is fast. The performance is on par with staticpool and
even faster on high contending situation. I hope that new glibc-malloc
is also fast. So I drop the patch.
With this malloc performance, usage of AVBufferPool on audio frame
More information about the ffmpeg-devel