OOo startup speedups

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.

Another effort in this area is Caolan's great unifysound01 CWS which removes nas, sndfile and portaudio from the VCL dependencies.

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

ccache for MSVC

For those building OpenOffice.org on Win32, it might be interesting that I've extended ccache to deal with MSVC. I've done it during our Novell HackWeek; I hope you'll enjoy the result as much as I enjoyed the hacking ;-)

It is easy to use, instead of guw.exe /path/to/cl.exe, you'll use guw.exe ccache.exe /path/to/cl.exe in your CXX environment variable after having sourced the environment. To see the ccache statistic, use ccache -s. You can override the directory where is the cache stored by exporting CCACHE_DIR="c:\where\you\want". Should you find any bugs, please send me patches :-)

I've not measured the speedup too much yet, but it was >20% in vcl compared to non-ccache run, the penalty of the initial fill of the cache was like 17% [compared to non-ccache]. Would be great if someone did a measurement of the entire build.

The patch and the binary are here, some more info there.

OpenOffice.org git repository

You could have seen already two blog entries about a new SCM for OOo (Is Subversion OOo's next revision control system? (by Nils Fuhrmann) and OpenOffice.org SCM) (by Jens-Heiner Rechtien), who seem to prefer Subversion. But I would rather go the git way, because this could tighten the cooperation between ooo-build and up-stream; namely the features or fixes could be much more easily integrated from ooo-build back to up-stream.

From my point of view:

• git should be used just for the source code, not for the project WWW pages. I don't care about the tool used for the WWW pages - I think that CVS is perfectly sufficient for them, I don't think it's really necessary to convert them to anything else (no extensive branching there, they change just occasionally, etc.)
• The OOo code should be split to 2 parts - the source code itself, and the 3rd party code that is just a verbatim or a slightly patched version of free libraries (agg, beanshell, berkeleydb, bitstream_vera_fonts, boost, ..., zlib). The contemporary Linux distros are able to compile without them, using --with-system-libs configure option; on Win32 we could ship a pre-compiled pack - no need to recompile these again and again.

The OpenOffice.org git repository for testing purposes is now available at http://go-oo.org/git/ - feel free to try it. More about the topic is in the OOo Wiki.