[gstreamer-bugs] [Bug 503592] gstpad.c does many ref/unref of peer pad in dataflow

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=503592
  GStreamer | gstreamer (core) | git

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at gmail.com

--- Comment #22 from Edward Hervey <bilboed at gmail.com> 2010-10-16 16:42:44 UTC ---
Felipe, are those numbers speedup using those patches ? If so, it's already a
great start.


The issue with queue is a separate one I'm working one (based on
brainstorming/prototyping/past-experience from both wim and myself), involving:

* not take *any* lock when queue is neither full nor empty (goodbye context
switching for cases where rate of data coming in is similar to rate of data
coming out, which is the case for pipelines with live sources/sinks).

* If needed (queue empty/full) only take a lock to signal the other thread of a
change in levels (i.e. you only take the lock to wakeup/wait-on a conditional
and nothing else, as opposed to right now where a mutex is taken over the whole
queue processing), limiting the amount of time of context switching.

* allocation-less as much as possible (relying on grow-only arrays with sane
default sizes as a replacement to glib's GQueue). This feature alone introduce
a 33% speedup in throughput due to the reduced cost of passing data from one
thread to another, for a minimal extra expense in memory being used.

I'll open a bug report about this on monday once I've cleaned up my work branch
and commented the code.

In the end, we should end up with the overhead of queue being the same as the
overhead of a 'dumb' element like identity, while benefiting (and relying) on
the kernel for proper load balancing (beneficial on single core, multi-core,
with/without hw-accelerated use cases).

Other ideas that could be worked on afterwards would be using the min-threshold
properties to throttle the cases where the data coming in is (much) faster that
the speed at which data is pulled out, thereby reducing the wakeups on the
producer (file read / demuxer / decoder) side and only wakeup one side or the
other when the levels are within X units of the min/max.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.