[gst-devel] How to decrease CPU consumation for audio recording?

Felipe Contreras felipe.contreras at gmail.com
Sat Oct 16 17:04:51 CEST 2010


On Thu, Oct 7, 2010 at 8:37 PM, Felipe Contreras
<felipe.contreras at gmail.com> wrote:
> 2010/10/7 Sebastian Dröge <sebastian.droege at collabora.co.uk>:
>> On Thu, 2010-10-07 at 18:39 +0300, Felipe Contreras wrote:
>>> [...]
>>> My speculation is that so much contention trashes the cache, that's
>>> why the performance degrades exponentially.
>>> [...]
>>
>> Of course performance degrades exponentially if you increase the number
>> of buffers exponentially ;)
>>
>> Unless I'm missing something, your x-axis has a logarithmic scale, which
>> would make your exponential curve a linear one in number of buffers.
>
> That is a good point, if you plot this per-buffer, the graph looks the
> other way around, however, the queue version on ARM converges to 0.8
> as opposed to 0.1, so, just introducing the queue degrades the
> performance by a factor of 8 per-buffer.
>
> I'll re-run the test with linear buffer size progression, but first
> I'm going to try to generate some contention, to see if something more
> interesting happens.

Ok, after thinking about this, I think the logarithmic progression is
correct as that matches what people actually do; it's the only sane
way to map the range from 10ms to 1s.

Anyway, the interesting thing is the CPU time spent per buffer, which
is 0.078, so in a realistic scenario of pushing one buffer each 10ms,
the usage would be 0.78% (just _one_ buffer through _one_ queue), so
of course the graph looks alarming. Even on my PC with 1.8ghz and two
cores the number would be 0.16%.

I've updated my blog post with these findings.

-- 
Felipe Contreras




More information about the gstreamer-devel mailing list