Apache OpenOffice (AOO) Bugzilla – Issue 98052
OOo on MAC needs long time to be responsive (maybe due to JVM start?)
Last modified: 2013-08-07 15:31:14 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.)
Please attach a sample document.
Any file will do. Here's one.
Created attachment 59434 [details] a document that had spinning beach ball problems
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.
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.
Forgot to change status to NEW.
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.
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.
@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.
Created attachment 60901 [details] flat profile of first-keypress in Writer
Maybe issue 99485 ("Help menu needs long time to open on Mac") is also affected by this (or at least same root cause)?
> 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...
reassigning to me though it is a framework issue
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.
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
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: http://wiki.services.openoffice.org/wiki/Framework/Article/Generic_UNO_Interfaces_for_complex_toolbar_controls
I can also reproduce this on 3.0.1 RC 2 and DEV300m44 on a PPC Mac.
*** Issue 100790 has been marked as a duplicate of this issue. ***