[gst-devel] possible optimisations in pad_push mutex handling
Gruenke, Matt
mgruenke at Tycoint.com
Mon Oct 11 19:46:16 CEST 2010
________________________________
From: Marco Ballesio [mailto:gibrovacco at gmail.com]
Sent: Monday, October 11, 2010 12:46
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] possible optimisations in pad_push mutex
handling
<snip/>
> P.S. it appears the penalty decreases when buffers have bigger
sizes,
> as already shown from Felipe.
That's not what that test showed, it showed that the more
buffers you
push per second, the more CPU you consume, which is rather
obvious.
> well, not for me ;). In a perfect world the algorithm should increase
in complexity wrt
> the quantity of data, and not depending on how it's partitioned. The
algorithm should
> be O(1) in this terms, and my patch tends to proof this.
Wim is correct (it's not the actual size of the buffers, but their
frequency that matters), but I think your point is that it doesn't mean
there's not still an issue to be addressed? Ideally, GStreamer to have
no overhead, but it doesn't (and nothing will). I think the key point
is that the per-buffer overhead is *significant*, for your application,
so you're interested in looking at ways to reduce it.
We also have scenarios where GStreamer overhead is significant (i.e.
handling lots of compressed streams on a server platform), so there's
broader interest in trying to reduce overhead. However, since we also
modify running pipelines, we're very interesting in that functionality
continuing to work.
<snip/>
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101011/df491b97/attachment.htm>
More information about the gstreamer-devel
mailing list