If I do not misunderstand your meaning, you want to combine all plugins into application. But if that, all plugins are combined together, the library will be very big. If an application is a music player, it will combine all demuxers and decoders together, and launch these at the same time whatever they are needed for one special playback. I think it will be slower than just loading application needed. Best Regards Zhao Liang -----Original Message----- From: gstreamer-embedded-bounces at lists.sourceforge.net [mailto:gstreamer-embedded-bounces at lists.sourceforge.net] On Behalf Of Nicholas Hannah Sent: Friday, February 29, 2008 9:23 AM To: gstreamer-embedded at lists.sourceforge.net Subject: Re: How to reduce gstreamer library size &startuptime Hi All, I have ported Gstreamer to a small embedded OS. I statically link all plugins that I need for a particular pipeline and explicitly call their initialisation routines. This means I don't need to scan for plugins or run any dynamic module loading code. I haven't done any proper tests to see how this reduces running time or code size but it is noticeably quicker to start up (especially when debugging is turned on) than a standard install. Let me know if anyone is interested in how I did this. As an aside I think that static linking is a good option for embedded systems because: 1) small OS's don't always (usually?) have a dynamic loader or dlopen(), dlsym() etc, 2) as mentioned earlier, in embedded environments new plugins probably won't be installed very often, so dynamic module loading is less useful, 3) switching off all dynamic loading code will result in overall smaller code size and better performance. In my opinion it would be nice if Gstreamer had better support for static linking. Regards, Nick > Hi, > > On Thu, 2008-02-28 at 10:28 +0100, Wouter Cloetens wrote: > > On Thu, Feb 28, 2008 at 05:23:40PM +0800, Zhao Liang-E3423C wrote: > > > 1. disable many unused features > > > 2. disable debug/trace > > > 3. use binary registry or not use registry 4. disable runtime > > > check > > > > Has anyone considered statically linking plugins? I suspect that > would > > be a rather big change, but you would win on startup time, in memory > > consumption and in runtime CPU usage. > > Most likely, the biggest time consumption in initialization is > checking for modifications of plugins (scannning directories, looking > at timestamps, loading them if changed, ....). > > We *could* add an option to NOT do that scanning at startup (if an > environment variable is set when running for example) and just load > the available registry. > In embedded environments you are most likely not installing new > plugins very often, so this checking is almost never used but might > cost a lot. > > You are of course then left with the cost of loading the actual > plugins required by the application afterwards, but that's after > initialization. > > Has anybody done some timing to see how long gst_init() takes ? > > Edward > > > > > bfn, Wouter > > > > > ---------------------------------------------------------------------- > --- > > This SF.net email is sponsored by: Microsoft Defy all challenges. > > Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Gstreamer-embedded mailing list > > Gstreamer-embedded at li... > > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > > -- > Edward Hervey <edward.hervey at co...> > Collabora Multimedia >> > ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Gstreamer-embedded mailing list Gstreamer-embedded at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
