Recently I was working on removal of some libraries from the OpenOffice.org startup procedure. They are not needed immediatiely during the startup, and can be loaded later when the user decides to use the functionality, or they are not needed at all any more. It saves disk access and linking time; I measured the win of the changes described below (on an AMD Geode based system, 'simulated cold start' using sync ; echo 3 > /proc/sys/vm/drop_caches), and it went down to 14.2s from 15.5s in KDE, to 11.5s from 12.7s in Gnome, and to 9.3s from 9.5s in WindowMaker (the win is smaller there because gnome-vfs wasn't used there even before the changes). I believe there is more time to save, and I'll try to find it of course ;-) Now what exactly was there:
gnome-vfs was initialized immediately during startup to avoid a deadlock. It has to be initialized in the thread as the Gtk+ itself; so moving the initialization to the main thread solved the problem, and gnome-vfs was removed from the startup. See issue 84137 for more.
Form controls in an empty document are initilized during startup because they are in 'design mode' (the user is able to create new form controls). This makes sense of course, but before the user creates the first form control, it is not necessary to load libfrm and all its dependencies - lots of users don't need form controls for their documents at all. See issue 84259 for more.
First start wizard is presented to the user during the first start of OOo to offer registration and migration of the settings from the previous version of OOo. Unfortunately, library that does this is loaded every time the OOo is started - just to check that there's nothing to do. See issue 84169.
localedata_es is a dependency of localedata_euro just because of one entry that can be easily moved to localedata_es itself. Very cheap win ;-), see issue 84206.
libstartup-notification was removed, because up-stream has never used it, and we (ooo-build) do not use any more either because of the external splash that we are trying to push up-stream for quite some time (another nice win, by the way). See issue 84179.
One problem here is that we remove some stuff from the startup, and other creeps in. Michael had an idea to introduce a kind of OSL_ASSERT_NOT_BOOSTRAP() macro that would be added to the init functions of the components that for sure should not be in the startup procedure, and check for that in smoketest. I'll try to produce a patch for that shortly as well...