[gst-devel] plugins split

[Thomas Vander Stichele]

Hi Dave,


> 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.

I wish you had numbers too :) There are some reasons why I don't think
combining plugins together is a good idea.  I regularly while testing
fixes copy .so files over my installed ones, or give them to other
people for testing, before actually commiting fixes.  As we move closer
to 1.0, I'd also want us to work towards a simple system where this
concept of plugins is used more.  For example, I want people to have a
directory in their homedir to drop plugins in and have them overrule the
system ones.  I want us to have an online repository of plugins.  After
all, that's why they're plugins.

Lumping all of them together seems to contradict that idea.  Exactly how
many would you lump together typically ? Shouldn't we check to see if
this actually gains us much ?


> 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.

Interesting.  Sounds like a good idea from what little I can tell.

Thomas
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Buffy ...
If I wanted to fight, you could tell
by the being dead already
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/