[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