On Sun, Jan 21, 2018 at 7:11 PM, wm4 <nfx...@googlemail.com> wrote: > On Sun, 21 Jan 2018 10:24:21 +0700 > Muhammad Faiz <mfc...@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 >> complicated. > > 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 becomes questionable. Thank's. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
