Apache OpenOffice (AOO) Bugzilla – Issue 114705
Templates and Documents dialog needs too long to open the first time
Last modified: 2017-05-20 10:22:32 UTC
1. use Solaris Sparc where this issue can be seen best 2. remove your user profile 3. choose FILE / NEW / TEMPLATES AND DOCUMENTS ==>> there pops up an empty not repainting dialog On my machine I have to wait 2 minutes until the dialog came up.
CCed: oc
Created attachment 71876 [details] callgrind profile of template initialization as .dot file
Created attachment 71877 [details] callgrind profile of template initialization as PNG
Please see the attached results of callgrind profiling the scenario.
Just some measuring : OOO320 m18 (aka 3.2.1): 10 seconds to open the dialog OOO330 m6: 240 seconds.
mav->sb: Sending to you for investigation as discussed. The most time seems to be spent in ::configmgr::Components::writeModifications(), triggered by creation of a new hierarchical content. Since the template initialization creates a lot of new contents, it is called very often. It is still a question, why does it work so fast on other platforms. For example, on Solaris-Intel ( v20z-so6 ) and Linux ( v20z-so4 ) the opening of the dialog takes about 10s as before.
@msc: On which machine can you observe the long delay? Background: The old (3.2) configmgr implementation hat an optimization in its com.sun.star.util.XChangesBatch.commitChanges implementation, to asynchronously write the modified per-user configuration data. The new (3.3) configmgr implementation writes its per-user registrymodifications.xcu file synchronously. Installing OOO300_m9 OOo with fresh UserInstallation, starting soffice for the third time (to get past the first/second start dialogs), doing File -> New -> Templates and Documents, Cancel, and File -> Exit, results in writing registrymodifications.xcu 114 times, on both unxlngi6.pro and unxsols4.pro. With a really slow harddisk, this could explain the observed delay. However, on both v20z-so4 (unxlngi6.pro) and v240-so3 (unxsols4.pro), any delay was hardly noticeable for me.
The magic difference apparently is to use Oracle Open Office instead of plain OOo. The former probably has more templates, and the delay is indeed clearly noticeable with it on unxsols4.pro v240-so3 (and slightly noticeable, like the 10s mentioned above on unxlngi6.pro v20z-so4). The number of writes of registrymodifications.xcu rises to 771, and temporarily removing the writes from the code reduces the unxsols4.pro v240-so3 delay to a time similar to the 10s on unxlngi6.pro v20z-so4. That is, I will need to add asynchronous writing of registrymodifications.xcu to the new configmgr implementation.
When fixing this, support for EnableAsync (aka lazywrite) can also be implemented again.
*** Issue 114676 has been marked as a duplicate of this issue. ***
adding to meta issue
fixed as <http://hg.services.openoffice.org/cws/sb133/rev/4013afbf3a42>; re-enabling EnableAsync is left for new issue 114911
plus <http://hg.services.openoffice.org/cws/sb133/rev/627d9ea842be>
plus <http://hg.services.openoffice.org/cws/sb133/rev/17933879015f>
@msc: please verify; fix is non-trivial (an additional thread to write registrymodifications.xcu asynchronously, which needs coordination during process shutdown), so please check thoroughly for regressions (lost changes to configuration data, crashes during shutdown, things like that; note that different platforms execute different code paths in class Desktop during shutdown, and that a special new kind of "shutdown directly after startup" has been introduced with jl's recent modifications to the Extension Manager; all this needs to be checked)
Adding me to CC
verified in CWS sb133 find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb133
Fix failed for Mac OS X. If you have documents open while quitting (via Option-Q etc.), OOo will erroneously consider those documents as to-be-recovered-after-a-crash upon next start. The problem is that the new FlushConfiguration is called too early in Desktop::QueryExit (which is used to terminate OOo only on Mac OS X; other platforms use other code paths, see issue 114937), before logic elsewhere (probably triggered by the call to xDesktop->terminate()) cleans up information stored in the configuration. The fix appears to be to move the call to FlushConfiguration down within Desktop::QueryExit, namely ---8<--- --- a/desktop/source/app/app.cxx +++ b/desktop/source/app/app.cxx @@ -785,7 +785,6 @@ { RTL_LOGFILE_CONTEXT_TRACE( aLog, "<- store config items" ); utl::ConfigManager::GetConfigManager()->StoreConfigItems(); - FlushConfiguration(); RTL_LOGFILE_CONTEXT_TRACE( aLog, "<- store config items" ); } catch ( RuntimeException& ) @@ -817,6 +816,7 @@ } else { + FlushConfiguration(); try { // it is no problem to call DisableOfficeIPCThread() more than once ---8<---
.
*** Issue 115114 has been marked as a duplicate of this issue. ***
fixed as <http://hg.services.openoffice.org/cws/sb134/rev/fd777518be3b>
@msc: please verify
verified in cws sb134. The problem from issue 115114 is fixed.