Issue 114705 - Templates and Documents dialog needs too long to open the first time
Summary: Templates and Documents dialog needs too long to open the first time
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO330m8
Hardware: Sun Solaris
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: marc.neumann
QA Contact: issues@framework
Keywords: regression
: 114676 (view as issue list)
Depends on:
Blocks: 111112
  Show dependency tree
Reported: 2010-09-23 14:58 UTC by marc.neumann
Modified: 2017-05-20 10:22 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

callgrind profile of template initialization as .dot file (25.31 KB, text/plain)
2010-09-28 16:53 UTC,
no flags Details
callgrind profile of template initialization as PNG (1.17 MB, image/png)
2010-09-28 16:55 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description marc.neumann 2010-09-23 14:58:36 UTC
1. use Solaris Sparc where this issue can be seen best
2. remove your user profile
==>> there pops up an empty not repainting dialog
On my machine I have to wait 2 minutes until the dialog came up.
Comment 1 oc 2010-09-27 08:13:23 UTC
CCed: oc
Comment 2 2010-09-28 16:53:50 UTC
Created attachment 71876 [details]
callgrind profile of template initialization as .dot file
Comment 3 2010-09-28 16:55:57 UTC
Created attachment 71877 [details]
callgrind profile of template initialization as PNG
Comment 4 2010-09-28 16:57:40 UTC
Please see the attached results of callgrind profiling the scenario.
Comment 5 marc.neumann 2010-09-29 09:30:06 UTC
Just some measuring :

OOO320 m18 (aka 3.2.1): 10 seconds to open the dialog
OOO330 m6: 240 seconds. 
Comment 6 mikhail.voytenko 2010-09-30 11:19:31 UTC
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.
Comment 7 Stephan Bergmann 2010-09-30 12:56:24 UTC
@msc:  On which machine can you observe the long delay?

Background:  The old (3.2) configmgr implementation hat an optimization in its 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 and 
With a really slow harddisk, this could explain the observed delay.  However, on
both v20z-so4 ( and v240-so3 (, any delay was hardly
noticeable for me.
Comment 8 Stephan Bergmann 2010-09-30 13:24:34 UTC
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 v240-so3 (and slightly noticeable, like the
10s mentioned above on v20z-so4).  The number of writes of
registrymodifications.xcu rises to 771, and temporarily removing the writes from
the code reduces the v240-so3 delay to a time similar to the 10s on v20z-so4.

That is, I will need to add asynchronous writing of registrymodifications.xcu to
the new configmgr implementation.
Comment 9 Stephan Bergmann 2010-10-01 08:52:40 UTC
When fixing this, support for EnableAsync (aka lazywrite) can also be
implemented again.
Comment 10 eric.savary 2010-10-04 10:31:25 UTC
*** Issue 114676 has been marked as a duplicate of this issue. ***
Comment 11 mdxonefour 2010-10-04 12:39:45 UTC
adding to meta issue
Comment 12 Stephan Bergmann 2010-10-04 13:20:07 UTC
fixed as <>;
re-enabling EnableAsync is left for new issue 114911
Comment 13 Stephan Bergmann 2010-10-04 14:47:58 UTC
plus <>
Comment 14 Stephan Bergmann 2010-10-06 08:26:21 UTC
plus <>
Comment 15 Stephan Bergmann 2010-10-06 10:30:39 UTC
@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)
Comment 16 vitriol 2010-10-11 09:35:32 UTC
Adding me to CC
Comment 17 marc.neumann 2010-10-12 12:17:12 UTC
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:
Comment 18 Stephan Bergmann 2010-10-18 09:17:36 UTC
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

--- a/desktop/source/app/app.cxx
+++ b/desktop/source/app/app.cxx
@@ -785,7 +785,6 @@
         RTL_LOGFILE_CONTEXT_TRACE( aLog, "<- store config items" );
-        FlushConfiguration();
         RTL_LOGFILE_CONTEXT_TRACE( aLog, "<- store config items" );
     catch ( RuntimeException& )
@@ -817,6 +816,7 @@
+        FlushConfiguration();
             // it is no problem to call DisableOfficeIPCThread() more than once
Comment 19 Stephan Bergmann 2010-10-18 09:19:22 UTC
Comment 20 Stephan Bergmann 2010-10-19 08:33:21 UTC
*** Issue 115114 has been marked as a duplicate of this issue. ***
Comment 21 Stephan Bergmann 2010-10-19 08:49:41 UTC
fixed as <>
Comment 22 Stephan Bergmann 2010-10-19 12:47:37 UTC
@msc: please verify
Comment 23 marc.neumann 2010-10-20 08:48:49 UTC
verified in cws sb134. The problem from issue 115114 is fixed.