From: Erik W. <om...@te...> - 2001-06-21 03:04:39
|
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 <om...@te...> - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ |
From: Joshua N P. <vi...@po...> - 2001-06-21 04:46:08
|
On Wed, Jun 20, 2001 at 08:05:02PM -0700, Erik Walthinsen wrote: > 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. Huh? Generating XML is much easier than parsing it. When i wrote an XML generator in perl, i needed only about 40 lines of generic code to complement to the application specific stuff. |
From: Erik W. <om...@te...> - 2001-06-21 05:51:11
|
On Thu, 21 Jun 2001, Joshua N Pritikin wrote: > Huh? > Generating XML is much easier than parsing it. When i wrote an XML > generator in perl, i needed only about 40 lines of generic code to > complement to the application specific stuff. Oh, of course. I know that ;-) I'm just pointing out that someone has to go write it. Not that it's hard, but the issue is that glib has a scheduled freeze in less than 10 days, and getting them to include a <10day old API into glib is gonna be tricky. If you're interested it hacking up a generator API and the code behind it, please do so ;-) I'll help get it in glib if possible. I might even give it a try myself, if I have some time. TTYL, Omega Erik Walthinsen <om...@te...> - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ |
From: Joshua N P. <vi...@po...> - 2001-06-21 13:49:52
Attachments:
xml_out
|
On Wed, Jun 20, 2001 at 10:51:32PM -0700, Erik Walthinsen wrote: > On Thu, 21 Jun 2001, Joshua N Pritikin wrote: > > Generating XML is much easier than parsing it. When i wrote an XML > > generator in perl, i needed only about 40 lines of generic code to > > complement to the application specific stuff. > > Oh, of course. I know that ;-) > > I'm just pointing out that someone has to go write it. Well . . . my suggestion isn't completely vaporware. ;-) The attached perl code is what i'm using. i'm not a glib expert yet so it will take some time before i can offer a glib-ized version. Enjoy .. -- Get self-realization at <http://sahajayoga.org> ... <http://why-compete.org> ? Victory to the Divine Mother!! |