The Free and Open Productivity Suite
Released: Apache OpenOffice 4.1.15 Performance Tuning

This page contains a general list of areas that affect how fast the 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 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 performance issues

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

  1. Startup Time of the Application

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

    • Size of Application Binaries

      As the size of the 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 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 is being run.

      There are several ways to reduce the size of the application binaries and, in turn, decrease startup time without changing any of the 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 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 binaries on all Unix platforms except Mac OS X by executing the following command after you have completely built

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

        You can then install 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

    • Unused Code

      Removing any unused code would reduce the size of the binaries which, in turn, would reduce startup time. Since almost all the 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 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 Application

    Nearly all of the issues listed in the Startup Time section are equally applicable to post-startup speed of the 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 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 6.0 files (XML) see more

      Now the new file format of 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 6.0 files has to be checked in every application.

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



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

To Do's

To Do's



Responsible Engineer

Implement optional stripping of binaries on Unix platforms during creation of the 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 build instructions to reflect this new packaging option


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

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache, OpenOffice, and the seagull logo are registered trademarks of The Apache Software Foundation. The Apache feather logo is a trademark of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.