[gstreamer-bugs] [Bug 160126] multi.ogg is slow

[bugzilla-daemon at bugzilla.gnome.org]

http://bugzilla.gnome.org/show_bug.cgi?id=160126
GStreamer | gst-plugins | Ver: HEAD CVS

rbultje at ronald.bitfreak.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|multi.ogg file hang with    |multi.ogg is slow
                   |message about 0 occuring 3  |
                   |time                        |



------- Additional Comments From rbultje at ronald.bitfreak.net  2004-12-18 07:56 -------
OK, so I had a look at callgrind. Tried oprofile too, but we didn't appear to
like each other. I simply profile lt-totem multi.ogg, with audio resampling
disabled (it biases the whole thing, and it's not the culprit here). Here's some
numbers:

* probe_triggered()+callees in playbasebin takes 86.92% of the CPU time.
* half of this time (50.66%) is spent in gst_value_init_and_copy()+callees.
* direct callees taking time appear to be gst_element_set_state() (54.33%) and
g_signal_emit() (31.99%). This might imply that it renegotiates during both
state_chage *and* the signal emission (which, FYI, results in setup_sinks being
called in playbin). That would suck.
* gst_value_init_and_copy itself is responsible for 44.22% of the CPU time (in
the whole app). This implies that the use of data copying in caps negotiation
during chain switches is the bad factor here. Use of gst_value_init_and_copy()
outside the context of probe_triggered() is apparently negligible.
* gst_caps_is_subset(), which is a simple check (like g_return_if_fail() takes
28.30%. All of this time (98.62%) is spent in gst_value_init_and_copy().
* there's some more similar things...

Basically, I see that caps negotiation is horribly slow, mostly due to data
copying. The best thing to do, it seems, is to try and keep variables alive
while calling functions, rather than making copies. This whole thing is, of
course, rather exagerated by the use of arrays (for surround sound), which makes
this thing suddenly show off. Short-term, we can decide to either revert
surround sound alltogether or spend time optimizing core. I obviously prefer the
second.

If you want more specific numbers for other parts, let me know.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.