[gst-devel] possible optimisations in pad_push mutex handling

[Marco Ballesio]

Hi,

..snip..

> > 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 agree with you: it will never be possible to have a GStreamer completely
independent from the data partitioning. Generically speaking, it is possible
to have algorithms with such a characteristic, but I can't figure out
anything which would have a real applicability, for instance, in the VoIP
case.


> 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.
>

Yep, my point is that we're far from optimality, and I'm pleased in seeing
the most prominent community members with so many good ideas. My wish would
be to get something with a performance level close to the one of my patch
(and I know it's possible to do even better), but without any of the
penalties which make it completely useless for anything more than testing.

I'd also like to see find more areas of improvement like this one to be able
and get an "absolute minimum" we could get without major architectural
changes, but also to propose an optimised architecture for the time to
come..


>
>
> 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.
>

well, after seeing so many good ideas I'm not a great defender of my
original proposal, but it would work even in your case as the API includes
both a way to use an optimised path and another to go back to the old
(unoptimised) one in case the application needs to interact with the
pipeline.

Maybe I'll find some time to make the proof-of-concept patches presentable
and post them somewhere..

Regards



>
>
> <snip/>
>
>
>
>
>
> Matt
>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101011/1bce14ab/attachment.htm>