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 (many of them combined into larger .xcd files, which are just concatenations of multiple .xcs/.xcu files, to decrease file I/O times), and write all modifications to a single file $UserInstallation/user/registrymodifications.xcu (using a custom XML format based on the .xcu format)—and to optimize later. For now, a corrupted registrymodificaitons.xcu 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.
For OOo extensions containing configuration data, the extension manager now communicates with the configuration manager via a simple (non–UNO-based) C++ interface, through which the extension manager can register configuration data files and remove them again. Which extension configuration data files are registerd (in the shared resp. per-user store) is now recorded in registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/configmgrrc ini-files within the extension manager's cache directories (and those configuration data files are no longer merged into registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/registry trees, although for now those trees are still read out to cater for already installed extensions). At runtime, newly registered extension configuration data files are live-merged into the configuration manager's runtime data, while the effects of removing data files only become active on the next OOo start (rationale: if a configuration item is removed from a layer, the configuration manager at runtime has no information whether or not it hid an underlying item that now should become visible).
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.
As for a time line, the new code will definitely not go into OOo 3.2. More realistic targets are OOo 3.3 or, if file format incompatibilities require it, even OOo 4.

Some numbers, taken on the same Linux box where I did earlier measurements, show that the new implementation is currently about as fast as the old one. Currently, the new implementation uses libxml2's xmlreader API to read XML files (using libxml2's DOM-based API turned out to burn too many processing cycles, esp. in memory allocation, and libxml2's C-based SAX API is not very useful in a C++ scenario where the callbacks want to throw exceptions, and handling of .xcd <dependency> elements requires a mechanism to stop parsing prematurely). The callgrind numbers show that still too many processing cycles are spent reading the XML files in libxml2. With a bit of work, this could be replaced with a custom XML reader that would hopefully need fewer cycles and would hopefully speed up start up times. Comparing a plain unxlngi6.pro DEV300m54 OOo with (DEV300m54-based) sb111, /usr/bin/time -v opt/openoffice.org3/program/soffice -writer (and hitting Ctrl-Q when the text cursor starts to blink) gives the following numbers (one cold and two subsequent warm starts each):

	user	system	percentage	wall-clock	major page faults
plain	1.26s	0.23s	22%	6.75s	340
	1.32s	0.16s	51%	2.88s	1
	1.30s	0.16s	53%	2.76s	1
`sb111`	1.61s	0.30s	28%	6.66s	334
	1.53s	0.17s	65%	2.60s	1
	1.42s	0.16s	63%	2.48s	1

callgrind numbers, sorted per ELF-object:

plain			`sb111`
∑	2,620,343,316	100.00%	∑	2,705,655,238	100.00%
`sal`	686,659,333	26.20%	`sal`	519,735,216	19.21%
`ld`	330,253,794	12.60%	`xml2`	497,961,694	18.40%
`configmgr2`	314,864,471	12.02%	`ld`	303,513,949	11.22%
`c`	215,660,518	8.23%	`configmgr`	229,593,616	8.49%
`fontconfig`	205,835,897	7.86%	`c`	218,615,140	8.08%
`pthread`	117,283,877	4.48%	`fontconfig`	205,908,326	7.61%
`cppu`	116,507,422	4.45%	`pthread`	96,248,977	3.56%
`vcl`	92,381,398	3.53%	`vcl`	92,373,178	3.41%
…	…	…	…	…	…

Performance/Configuration

Status Quo

Improvement

Work in Progress

Views

Personal tools

Navigation

Search

Tools