OpenOffice.org Performance Tuning

This page contains a general list of areas that affect how fast the OpenOffice.org application runs. A brief description of the current and/or recent work is provided for each area. For application specific optimization possibilities see the project pages (e.g. for the Writer).

An overview of current and planned performance improvements can be found here.

In addition, a description of the profiling tools for each platform and how to use them within the OpenOffice.org build is provided.

If you would like to share any performance tuning work that you are currently doing or have already done, please send your suggested updates to for this page to martin.hollmichel@sun.com.

OpenOffice.org performance issues

Currently, OpenOffice.org application performance issues can be grouped into the following two categories:

1. Startup Time of the Openoffice.org Application

   There are several items that can influence the startup of an application:

   • Size of Application Binaries

     As the size of the OpenOffice.org application binaries increases, startup time increases. This increased startup time is due to the time required by the operating system to physically read the application executable and its shared libraries into memory. The increase in startup time is particularly noticeable when the OpenOffice.org binaries reside on mounted disk since the binaries need to be streamed across the network between the machine with the exported disk and the local machine where OpenOffice.org is being run.

     There are several ways to reduce the size of the OpenOffice.org application binaries and, in turn, decrease startup time without changing any of the OpenOffice.org source code:

     • Reducing the amount of code that is loaded at startup

       Ideally, all of the symbols necessary for startup would be put in separate binaries from the symbols used after startup. Also, the runtime linker would load only the startup binaries and would defer loading of the remaining binaries until after startup.

       Currently, Sun engineers in Cupertino, California are working on moving the existing Solaris Sparc build to be closer to the ideal. Click here for a detailed description of this effort.

     • Stripping the application binaries

       On all Unix platforms, the symbol table within each executable and shared library adds considerable size (approximately 40 MB on the Linux Intel and Solaris Sparc platforms). Since the symbol table is not needed at runtime, the strip command can be used to eliminate these extra size from the OpenOffice.org binaries on most, if not all, of the Unix platforms.

       Automatic stripping of Unix binaries is now available in the installation set creation process (see the To Do's section).

       You can enable stripping of the OpenOffice.org binaries on all Unix platforms except Mac OS X by executing the following command after you have completely built OpenOffice.org:

       cd $SRC_ROOT/instsetoo ; dmake "strip=true"

       You can then install OpenOffice.org as you normally would using the following command:

       cd $SRC_ROOT/instsetoo/$INPATH/normal ; ./setup

       Important note: The above commands will not strip binaries for builds before SRC634. So, if you want to enable stripping in an earlier build, you must execute the following commands before executing the above commands:

       cd $SRC_ROOT/scptools/source/linker
cvs update -A lzip.cxx scpzip.cxx
cd $SRC_ROOT/scptools ; dmake
cd $SRC_ROOT/instsetoo/util
cvs update -A makefile.mk

   • Unused Code

     Removing any unused code would reduce the size of the OpenOffice.org binaries which, in turn, would reduce startup time. Since almost all the OpenOffice.org binaries are shared libraries, analysis of each exported symbol could potentially determine which local symbols within each shared library not used and such symbols could be eliminated from the code. However, no work has been done in this area so the amount of unused code within the OpenOffice.org is currently unknown.

     Anyone who attempts such analysis should double check that their analysis includes any invocations of unexported symbols. Such invocations are frequently executed by the UNO runtime via v-table lookups and less frequently by the direct symbol lookup within the osl_getSymbol function in the sal/inc/osl/module.h source file.

   • Working Set

   • Memory Footprint

   • Hot Spots

2. Post-Startup Speed of the Openoffice.org Application

   Nearly all of the issues listed in the Startup Time section are equally applicable to post-startup speed of the OpenOffice.org application.

   In addition, the following items also affect post-startup speed:

   • Symbol Size Optimizations

     Potentially, the use of certain compiler or linker options can increase or decrease the size of binaries. For example, enabling exceptions on Solaris Sparc increases code size by a noticeable amount.

     Currently, Sun engineers in Cupertino, California are looking for compiler and linker options that can decrease code size. Since this is a difficult task to do given the large total size of the OpenOffice.org binaries, Sun engineers are analyzing the increases in binary sizes on Linux Intel and Solaris Sparc from StarOffice 5.2 to a recent build. Hopefully, by analyzing the changes in the list and/or sizes of the symbols in the binaries with the largest growth, specific types of compiler or linker options (and maybe even coding constructs) that cause symbol size to increase or decrease will be found. Stay tuned for updates.

   • Save/Load Optimization of OpenOffice.org 6.0 files (XML) see more

     Now the new file format of OpenOffice.org is feature complete and so it is time to analyse the performance.

     Now we have to find the own problems of the applications. The performance of Save/Load OpenOffice.org 6.0 files has to be checked in every OpenOffice.org application.

Here you can find some platform specific data for Windows, Linux and Solaris.

Tools

• Profiling

  By default, the OpenOffice.org build is not built for profiling. You can enable profiling by rebuilding each module that you want to profile by executing the following command:

  cd $SRC_ROOT/(module) dmake -u "profile=true"

  Sun engineers in have had some experience in using the profiler gprof on Solaris. Click here for a detailed instructions for using gprof on Solaris.

• Profiling II

  There is another environment which provides profiling data on a more abstracted level then the known (commercial) tools. The goal is to have a fully automatic process that generates, processes, and analyzes the profiling data. Please see this page contains further information.

• Optimized Link Processes (usage of mapfiles, minimizing exports, etc.)

Links

Here is a list of links that may provide some useful information.

• A discussion on how to tune Linux libraries. How to write shared libraries OpenOffice.org use a lot of shared libraries so this is worth a look.

• List Classes Discusses performance problems with OOo's internal List class

To Do's

To Do's
Task	Status	Responsible Engineer
Implement optional stripping of binaries on Unix platforms during creation of the OpenOffice.org installation set: Add new -S option to lzip and scpzip build tools and implement stripping of binaries on Unix platforms if the -S option is used Modify makefile in instsetoo module to invoke lzip with the -S option if dmake is run with "strip=true" Update OpenOffice.org build instructions to reflect this new packaging option	Implemented	Patrick Luby
Investigate reducing startup time for Solaris by deferring the loading of large files: Find out how to split the shared libraries that have only a few symbols invoked during startup. Find out how to do lazy linking and if it works the way we understand the linker supposed to work. Test the above to see how much reduction in startup time can be achieved, if any. Examine the large data files and see how their loading can be deferred after startup.	In Progress	Ping Liao
Investigate reducing the save and load time of OpenOffice.org 6.0 files (XML): Find where it needs how much time. Think about where and what to optimize. Test the above to see how much reduction in save and load time can be achieved, if any.	In Progress	Sascha Ballach (Spreadsheet) Daniel Vogelheim (Text) Björn Milcke (Chart) Christian Lippka (Draw/Impress)