[gst-devel] Slimming

[Erik Walthinsen]

I'm currently searching for as many ways to slim down GStreamer as
possible, with the target of getting libgst.so down to around 50KB.  A lot
of this is accomplished by removing all the masses of debugging present in
the form of adding a couple glib #defines and some configure arguments to
turn off the GST debug system (there's some work there to make those
configure arguments make more sense...).  There are a lot of other ways of
doing this:

1) Remove XML load/save.  I've got that almost entirely done now in my
local copy of HEAD.  I'll do some tests to verify that it worked then
commit.  There are some obvious potential pitfalls:

  a) making sure the right code is removed, and no more
  b) ensuring that code that tries to use the load/save features without
     them compiled in will fail, probably by using #error in macros that
     stub out the missing functions.

2) Removing other subsystems that might not be used in various [embedded]
environments:

  a) gst.c - most of this is command-line stuff, not relevant
  b) gstautoplug.c - embedded cases will be static or limited dynamic
  c) gstinfo.c - this is all code used for the DEBUG stuff, and can go
  d) gstparse.c - same reasons as gstautoplug.c
  e) gsttypefind.c - same as gstautoplug.c

3) The plugin system and registry could be removed, saving both the
gstplugin.c and the save_/load_thyself code in several other files.  This
would require some modifications to the way plugins are written to deal
with the fact that there may be implicit namespace collision in a static
build.  Possibly change the GstPluginDesc definitions to a macro that can
be stubbed as needed.

4) A lesser version of 3) would be to try to make use of the glib-2.0 XML
features, which are quite a bit smaller (and less featureful) than
libxml2.  Current problem is that there is no support for *writing* XML
files.  I hope this can be solved with the addition of such code to
glib-2.0, but the API freeze is in 10 days, so someone would have to work
very fast to pull that off.

Another option is to simply require that the registry be generated with a
copy of gstreamer that is linked against libxml2, and then copied to the
machine in question.  That's less appealing IMO.

5) General dead-code elimination.  There are several groups of code that
I've barely identified so far that are simply dead code, or no longer
relevant.  gstmeta.c is a really good example, gsttrace.c less so because
we may be reviving that module soon to do better run-time analysis of
what's going on.

6) Inspection of some of the functions that seem to be too large relative
to their functionality.  I have a short list of functions that are
suspicions (yes, I turned off inlining), and depending on how picky we
get, that list could get a lot longer.  A good example is
gst_object_set_parent, which should boil down to a few instructions (calls
to _ref, _sink, and _signal_emit), but instead is 276 bytes of code...

Does anyone have any other ideas for slimming?

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_