Issue 98052 - OOo on MAC needs long time to be responsive (maybe due to JVM start?)
Summary: OOo on MAC needs long time to be responsive (maybe due to JVM start?)
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m38
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 100790 (view as issue list)
Depends on: 100172 100177
Blocks: 99485
  Show dependency tree
Reported: 2009-01-14 02:57 UTC by lhorner
Modified: 2013-08-07 15:31 UTC (History)
6 users (show)

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

a document that had spinning beach ball problems (35.40 KB, application/vnd.oasis.opendocument.text)
2009-01-16 15:29 UTC, lhorner
no flags Details
flat profile of first-keypress in Writer (58.46 KB, text/plain)
2009-03-12 17:42 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description lhorner 2009-01-14 02:57:36 UTC
As soon as I open a text file (empty or old), OOo is sluggish.  I click some place to type: pause, spinning 
beach ball for 10s of seconds.  I hit return.  I go to a new cell in a table.  Almost everything I do seems to 
go to spinning beach ball.  It's frustrating.

(I'm not sure this is the right subcomponent.)
Comment 1 eric.savary 2009-01-16 14:38:43 UTC
Please attach a sample document.
Comment 2 lhorner 2009-01-16 15:26:45 UTC
Any file will do.  Here's one.  
Comment 3 lhorner 2009-01-16 15:29:03 UTC
Created attachment 59434 [details]
a document that had spinning beach ball problems
Comment 4 rvojta 2009-01-22 11:42:49 UTC
I have to confirm this issue with m39 too. Everything is very slow (my computer
isn't). It doesn't depend on a file. It happens with new file too. It takes ages
to write something, scroll or even write a simple text into a cell in Calc.

For example, in Calc - select cell, start writing, ... -> beach ball for a few
seconds -> text appears. Select another cell, start writing and it's fast as it
should be. Probably some font loading issue? Or ...

It looks like it's not Writer issue only, but all components are affected.
Comment 5 rvojta 2009-01-22 15:08:12 UTC
I just profiled it with Instruments and Shark and found, that OO.o spent 88 % of
'beach ball' starting JVM. I tried to disable JRE, start OO.o again and try to
enter simple text in a cell. But there's no way, because dialog that JRE is
needed appears.

Comment 6 rvojta 2009-01-24 19:32:41 UTC
Forgot to change status to NEW.
Comment 7 pkidwell 2009-02-23 14:59:18 UTC
I can confirm this on DEV310m1 Aqua/PPC, though it's only on the very first
action after starting OOo. After that, things seem to run normally. This would
be consistent with an issue loading/initializing JVM.  On a G5 iMac it's about a
5-7 second delay after first keystroke in Writer or Calc.
Comment 8 michael.ruess 2009-03-12 14:57:10 UTC
MRU->PL: please have a look. While using OOo on Windows, it is possible to type
e.g. in Writer right after seeing the document. On Mac, it takes about 5 seconds
to see the typed text after the view is visible.
Comment 9 2009-03-12 17:39:23 UTC
@cd: I profiled the use case MRU mentioned (empty Writer, first keypress -> long wait) and the problem 
here starts with MenuBarManager::Activate(Menu*) calling MenuBarManager::RetrieveShortcuts() and then 
the rest of the long wait seems to be in the ConfigurationManager.... and all this multisecond-wait just to 
check if a friggin accelerator key was pressed?

I have the shark-profile of the use case. Exploring it is mostly an interactive thing, but it did generate a 
report too which I will attach.
Comment 10 2009-03-12 17:42:06 UTC
Created attachment 60901 [details]
flat profile of first-keypress in Writer
Comment 11 michael.ruess 2009-03-13 11:28:24 UTC
Maybe issue 99485 ("Help menu needs long time to open on Mac") is also affected
by this (or at least same root cause)?
Comment 12 2009-03-13 15:12:10 UTC
> Maybe issue 99485 ("Help menu needs long time to open on Mac") is also affected by this (or at least 
same root cause)?

Seems so. The changes I suggested in issue 100172 and issue 100177 reduce it from about 4sec to less 
than 1sec. That is still one second too much... still analyzing...
Comment 13 2009-03-13 15:14:45 UTC
reassigning to me though it is a framework issue
Comment 14 carsten.driesner 2009-03-17 10:16:07 UTC
cd: Please keep in mind that Java based extensions must be started if the
extension inserts menu items into the menu bar. The framework implementation
needs to get the latest state of every menu item. Therefore the Java based
implementation must be called to retrieve the state. This cannot be workaround
and is also true for every other system. All further menu access should be
faster as the JVM has been started.
Comment 15 2009-03-25 12:32:52 UTC
So with issue 100172 and issue 100177 fixed for OOo 3.1 there is only the remaining problem CD 
mentioned: framework currently always starts extensions even if just their latest status is needed, which is 
especially expensive if they are based on external programs such as java or python. Maybe the start of an 
extension can be delayed, e.g. the latest button or menu status of an extension could be cached. The 
extension only needs to be started if its buttons get hit.
This remaining task is in the framework project -> reassigning
Comment 16 carsten.driesner 2009-03-25 13:59:59 UTC
cd: There is no solution for this problem. Your proposal doesn't work for most
cases when the state of a button is dependent on special other states (e.g.
document read-only, document modified, ...). The code cannot use the last state
for these buttons as this would be a in 99% a wrong state! For extensions which
want to have dump buttons they can circumvent this problem using the "Button"
control in the Addons.xcu. See:
Comment 17 vendion 2009-04-03 13:20:26 UTC
I can also reproduce this on 3.0.1 RC 2 and DEV300m44 on a PPC Mac.
Comment 18 eric.savary 2009-05-13 20:41:45 UTC
*** Issue 100790 has been marked as a duplicate of this issue. ***