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
Status: CLOSED FIXED
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
URL:
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: ---


Attachments
callgrind profile of template initialization as .dot file (25.31 KB, text/plain)
2010-09-28 16:53 UTC, hdu@apache.org
no flags Details
callgrind profile of template initialization as PNG (1.17 MB, image/png)
2010-09-28 16:55 UTC, hdu@apache.org
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
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.
Comment 1 oc 2010-09-27 08:13:23 UTC
CCed: oc
Comment 2 hdu@apache.org 2010-09-28 16:53:50 UTC
Created attachment 71876 [details]
callgrind profile of template initialization as .dot file
Comment 3 hdu@apache.org 2010-09-28 16:55:57 UTC
Created attachment 71877 [details]
callgrind profile of template initialization as PNG
Comment 4 hdu@apache.org 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
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.
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 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.
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 <http://hg.services.openoffice.org/cws/sb133/rev/4013afbf3a42>;
re-enabling EnableAsync is left for new issue 114911
Comment 13 Stephan Bergmann 2010-10-04 14:47:58 UTC
plus <http://hg.services.openoffice.org/cws/sb133/rev/627d9ea842be>
Comment 14 Stephan Bergmann 2010-10-06 08:26:21 UTC
plus <http://hg.services.openoffice.org/cws/sb133/rev/17933879015f>
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:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb133
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

---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<---
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 <http://hg.services.openoffice.org/cws/sb134/rev/fd777518be3b>
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.