[gst-devel] merging elements in plugins

[Thomas Vander Stichele]

Hi,


> Attached. Should be against HEAD/CVS of this morning (unmodified) with
> my registry/staticpadtemplates patch applied (although it doesn't use
> any of that; but that's what I test it with), which looks pretty much
> like HEAD/CVS of the end of today.

I changed the patch a little to be more accurately reflecting what we're
testing:

- we're trying to find if there's a measurable difference between having
some elements in the same .so or in different .so files.  Effectively
this means measuring the time to do gst_element_factory_make().
creating pipelines, linking, ... is all extra overhead that would skew
the results by making the relative difference between the two methods a
lot smaller
- using gnomevfssrc as part of that benchmark is not a good idea; it
needs additional libs.  The discussion was about dependency-less
plugins.  I kept it in a separate timing for reference to see the
influence of being linked to other libs as well.
- I'm not sure if the code paths for a "local" plugin is the same as for
a .so plugin, modulo the dlopen().  Did you check this ?

Make sure you tell me if I'm doing something wrong here ! I didn't look
at the timing before my changes to not bias my test towards what I think
is right :)

Anyway, with these changes, I get as the output from three consecutive
runs (on my laptop, Pentium-M 1300 MHz, fresh boot, no other CPU or disk
activity other than normal stuff:

[gst-head] [thomas at otto tests]$ ./speed
Init time: 0:00:00.467307000
2 Plugins, 2 elements, make time: 0:00:00.004580000
1 Plugin, 1 element, make time: 0:00:00.022268000
1 Plugin, 1 element, external lib, make time: 0:00:00.102910000
Local elements time: 0:00:00.000091000
[gst-head] [thomas at otto tests]$ ./speed
Init time: 0:00:00.465248000
2 Plugins, 2 elements, make time: 0:00:00.009456000
1 Plugin, 1 element, make time: 0:00:00.021845000
1 Plugin, 1 element, external lib, make time: 0:00:00.094020000
Local elements time: 0:00:00.000091000
[gst-head] [thomas at otto tests]$ ./speed
Init time: 0:00:00.482640000
2 Plugins, 2 elements, make time: 0:00:00.004128000
1 Plugin, 1 element, make time: 0:00:00.023481000
1 Plugin, 1 element, external lib, make time: 0:00:00.215684000
Local elements time: 0:00:00.000093000

What I draw from this:
- the 2 plugin test's time varies by a factor of 2.  I've seen worse in
some more runs.  Not very dependable to base a result on.
- the 1 plugin test is actually *slower* than the 2 plugin test.  I
guess this is because ffmpegcolorspace has a larger codebase.  Or maybe
because it has a lot more pad templates and a lot more caps to handle.
This would seem to indicate that the size of the binary is actually a
more important factor in plugin loading time.  I'd assume chucking
elements together in a plugin would not reduce the code size :) Maybe it
would even be correct to say that loading a plugin from which you don't
need 75% of the elements in your code actually *slows down* startup time
than when the plugins would be separate ?
- The time to create one element is still less than 5% of the _init
time.  Seems better to optimize _init ?
- The element with an external lib takes 4 times longer to load than
ffmpegcolorspace.  We weren't planning on throwing together elements
that did have external dependencies, and given this result that's indeed
a safe choice to make.

So as my conclusion, I'd say that there really isn't a noticeable gain
by throwing elements together in a .so file.  .so file size seems to be
a more deciding factor for how long it takes to load the plugin, and
that means it might be bad to throw them together - it causes you to
load more plugins than you need, taking more time than you should take.

As a question, wouldn't it be better to just profile normally and
measure time spent in dlopen for these tests ? The variation in numbers
suggests this is not that good of a test method to begin with. 

Please hit me with a cluebat for everything I've done wrong in this off-
the-cuff analysis :)

Changed patch attached; apply from toplevel.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If you don't ask me out to dinner
I don't eat
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: speed.patch
Type: text/x-patch
Size: 2044 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20050413/cdbb7c06/attachment.bin>