[gst-devel] plugins split

[David Schleef]

On Thu, Mar 10, 2005 at 05:36:45PM +0100, Thomas Vander Stichele wrote:
> Hi gang,
> 
> I made a (preliminary) "gst-plugins-base" module in CVS.  I didn't want
> to reuse the old gst-plugins because branches are all attached to a
> module, and I wanted to keep some history.
> 
> Attached is a patch that shows how I made make recursion under gst/ one
> level less deep in most cases.  This also speeds up the autogen process
> a bunch.  It has some side effects though, so you might want to give
> this patch a try and comment on the issues involved.

All elements that have no dependencies should be a part of a single
plugin.  The CPU cost for the bundle is a few extra relocations at
load time; the CPU cost for separate plugins is that each shared
object file has to be loaded, which requires a lot of CPU cycles.
Similar for memory -- a bundle will use more memory than the average
separate plugin, but a bundle causes less fragmentation.  I wish
I had actual numbers for all of this.  Right now, it's just
educated guesses.

Also, one key issue is that if we use bundles, we should change
element registration so that GObjectClasses are not registered until
right before the corresponding element needs to be instantiated.
Otherwise, the cost of class registration overshadows any gains.

Of course, bundling make embedded usage a bit more difficult, but
the current solution is merely mediocre for embedded.  I'd prefer
to mix stuff up and actually create a good solution if people want
it.

Oh yeah -- and core elements should be bundled in libgstreamer.so.



dave...