[gst-devel] Pretty graphs

[Andy W. <wi...@po...>]

Hey folkses,

I've been doodling around with some, well, not exactly profiling, but
something a bit less formal.

First, I wanted to see what the performance difference was in 0.8 versus
THREADED with regards to the mass_elements test in gstreamer/tests.
mass_elements is just fakesrc ! N * identity ! fakesink. I also wanted
to see the performance of gstreamer with regards to N.

With normal CFLAGS (-g -O2), all the debugging enabled, etc -- a normal
build -- here are my results for 0.8 (well, really HEAD) and THREADED:

http://wingolog.org/pub/mass-elements-0.8.ps
http://wingolog.org/pub/mass-elements-THREADED.ps

The hiccups in the THREADED one are cache-related, I think, and
reproducible. Interesting that THREADED does so well, considering it
takes 2-3 locks per element per iteration. The reason the state change
is painful in 0.8 is because of the fixation before data flow. Element
creation (which includes linking while NULL) is still quadratic though,
as can be seen by

http://wingolog.org/pub/mass-elements-THREADED-5000.ps

which has more elements.

Another thing I wanted to see was the effect of pipeline "complexity" on
performance. In this case I could only test HEAD, as the THREADED tee
isn't ported yet. This is what I mean by "complexity":

3 elements, complexity 1:
fakesrc ! tee ! tee ! fakesink

3 elements, complexity 2:
                /-> fakesink
fakesrc -> tee 
                \-> fakesink

The one fakesrc is always counted extra. Anyway this test is in
tests/complexity.c, and the results for HEAD are here:

http://wingolog.org/pub/complexity-0.8.ps

Note that creation and destruction are insanely non-linear, probably due
to the use of linked lists everywhere combined with a scheduler that
recalculates groups at every link/unlink. Especially because all the
elements are in one group.

Well that's that. Don't take it too seriously. But the performance in
THREADED does look quite nice!

Cheers,
-- 
Andy Wingo
http://wingolog.org/