Performance/Configuration

Performance Project performance.openoffice.org
Quick Navigation Project Wiki Home Project Web Home Project Wiki Category Team Team Members Communication Mailing Lists Meeting Minutes Activities ToDo List
About this template

Status Quo

The OOo configuration (aka registry; module configmgr) has various problems:

• Reading/stat'ing its many data files upon start up has negative impact on start up performance (see Performance/Startup#strace). A secondary performance problem might be the amount of configmgr code executed (see Performance/Startup#callgrind). See issue 101955 “improve configmgr performance”.
• There are various open issues relating to the configuration, for example:
  • issue 100548 “config data deployed via extension is still available after deinstallation and office restart ”
  • issue 88162 “Removing blank lines from a .xcu file to reduce its size”
  • issue 101422 “set nodes can't be reset correctly via configuration API”
  • issue 94456 “unnecessary Writer-javamail.xcu module”
  • issue 77102 “removeByName() for set nodes should remove them realy in XCU file”
  • issue 65160 “live deployment of configuration files does not work right”
  • issue 77200 “Assertion in config manager when installing extension”
  • issue 80296 “Reinstallation of an addon does not activate the new version completely.”
  • issue 60812 “refresh in configmgr leaves invalid items in cache”
  • issue 77174 “xsi namespace is missing in user registry files”
  • issue 53769 “Assertion: 45 times Error O:\SRC680\configmgr\source\treemgr\noderef.cxx Line 1371: (null)”
  • issue 46185 “API: cfgmgr2.OInnerTreeSetUpdateAccess::com::sun::star::container::XNameContainer”
  • issue 44715 “Set Update part of Config example needs to be rewritten”
  • issue 65845 “configuration should support IndexContainer/Access”
  • issue 52328 “Performance: configmanager”
  • issue 60022 “soffice with broken Common.xcu fails to start”
  • issue 60021 “soffice with broken Common.xcu does not terminate immediately upon user request”
  • issue 14471 “Configuration: cannot reinsert removed set elements without intervening commit”
  • issue 69360 “Support for localized values in extendable groups”
  • issue 56687 “User-Config corrupted if targetdir modified”
• I keep getting crash reports from configmgr code, some clearly from multi-threaded scenarios, some not. (See this mail.)

Improvement

All of the above, combined with the fact that the current configmgr code is hard to maintain—for me at least, made me consider a complete re-implementation of configmgr. The performance implications of reading/stat'ing the many data files during start up were clearly the most important factor here. This work is done on CWS sb111.

The intended steps are as follows:

• First, create a new implementation that has the same UNO API as the old one (it might leave out some obscure interfaces that are practically unused, anyway). It will continue to read the existing .xcs/.xcu files, but will (hopefully) be simpler and easier to maintain than the old implementation. I am currently working on this step.
• Second, improve (start up) performance by reorganizing the configuration's data files. What the best organization will look like is still open to experimentation. See Configmgr_Refactoring for related ideas.
• A further step might be to redesign the configmgr UNO API (and the relevant client code) to improve performance further, should measurements indicate that this is necessary.

Work in Progress

I do the improvements on CWS sb111. It is using Mercurial (instead of Subversion), and the Mercurial repository is available at http://hg.services.openoffice.org/hg/cws/sb111/ (which I sync with my local working repository more or less regularly).

Some notes, in no particular order:

• There are no overview documents yet. (The rationale is that design is still in big flux, so it is more convenient for me to work with notes on sheets of paper on my desk for now.)
• My simple approach for now is to read in all the .xcs/.xcu files during start up, and write all modifications to a single file $UserInstallation/user/registrymodifications (using a custom XML format based on the .xcu format)—and to optimize later. For now, a corrupted registrymodificaitons file (due to errors in the new code, for example) can prevent OOo from starting up; just remove the file in such a situation.
• There is no support yet for the system configuration layer, so especially the OOo locale will always default to en-US for now.
• There is no support yet for OOo extensions containing configuration data, so installing OOo can produce warnings (that bundled extensions like the various dictionaries for the different languages could not be installed) or even fail. Building installation sets with PKG_FORMAT=archive, or Mac OS X installation sets, will also fail, as it will try to install the bundled extensions at build time.
• For now, I concentrate on availability of basic functionality, like executing the smoke test document (somketestoo_native/data/smoketestdoc.sxw). Some code paths are not implemented yet (especially UNO API methods that appear to be rarely, if ever, used) and cause OOo to crash (to conveniently give me a stack trace when running OOo from within a debugger).
• I mainly work on Solaris Intel, so the code may occasionally have problems with other compilers.