Launchpad has imported 14 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=35270.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-03-13T13:52:07+00:00 szotsaki wrote: In either Writer or Calc when I open an existing, non-empty document it hangs for about 15 seconds until it loads the spell checker. If I turn that feature off the document loads swift next time. And it hangs again at that moment I turn that on. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/0 ------------------------------------------------------------------------ On 2011-03-15T09:54:52+00:00 Yfjiang wrote: Hi szotsaki, would you attach the file caused the problem? I didn't see this issue in my environment. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/1 ------------------------------------------------------------------------ On 2011-03-15T09:59:10+00:00 Yfjiang wrote: Ah, just realized may be the language tool causes the issue, how about the performance after removing languagetool packages? Thanks! Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/2 ------------------------------------------------------------------------ On 2011-03-17T11:38:20+00:00 szotsaki wrote: On openSUSE 11.4 I removed the libreoffice-languagetool and libreoffice- languagetool-en packages. There's no Hungarian variant of these. Interestingly, after removing these two packages the Hungarian spell- checker is still working and the performance issues are addressed. So, there's no slowdown. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/3 ------------------------------------------------------------------------ On 2011-12-23T19:52:39+00:00 Björn Michaelsen wrote: [This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org /RFC-Operation-Spamzilla-tp3607474p3607474.html Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/4 ------------------------------------------------------------------------ On 2011-12-24T01:02:01+00:00 Björn Michaelsen wrote: needinfo keyword redundant by needinfo status. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/5 ------------------------------------------------------------------------ On 2011-12-29T13:52:53+00:00 szotsaki wrote: As soon as I will upgrade to 3.5 final version with the help of my distribution's package manager, I'll recheck this bug. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/6 ------------------------------------------------------------------------ On 2012-04-28T22:48:11+00:00 dnaber wrote: I have finally come up with a detailed analysis: on each startup, the slow method SvxLinguConfigUpdate::UpdateAll() is called. A comment in the code suggests that this isn't needed anymore. Can we change the code like the comment suggests in unolingu.cxx, line 395? Namely using aAny <<= nCurrentDataFilesChangedCheckValue; instead of aAny <<= (sal_Int32) -1; // keep the value set to 'need to check' I have tested that this fixes the issue that this bug report is about. Here's in detail what happens on startup: doclay.cxx calls (*pLayIter)->GetCurrShell()->LayoutIdle(); layact.cxx calls ((SwTxtFrm*)pCnt)->_AutoSpell( pCntntNode, *pSh->GetViewOptions(), nTxtPos ); txtedt.cxx calls bSpell = xSpell.is() ? xSpell->hasLanguage( eActLang ) : sal_False; unolingu.cxx calls SpellDummy_Impl::GetSpell_Impl() finally, SpellDummy_Impl::GetSpell_Impl() calls this: if (SvxLinguConfigUpdate::IsNeedUpdateAll()) SvxLinguConfigUpdate::UpdateAll(); IsNeedUpdateAll() will return true, because aLinguOpt.nDataFilesChangedCheckValue is -1 because SvxLinguConfigUpdate::UpdateAll() will set it to -1, with a comment that this is only needed for <= OOo 3.0 ("for the time being (developer builds until OOo 3.0)..."). Thus after each startup, SvxLinguConfigUpdate::UpdateAll() gets called which takes a few seconds and blocks the machine. Another questions is why SvxLinguConfigUpdate::UpdateAll() is so slow and blocks. I haven't checked that out, as the change above fixes the problem. I have increased the 'version' property of this bug report because it also affects the latest version. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/7 ------------------------------------------------------------------------ On 2012-04-29T11:52:20+00:00 dnaber wrote: For reference, here's the comment from unolingu.cxx I was talking about above: // for the time being (developer builds until OOo 3.0) // we should always check for everything available // otherwise we may miss a new installed extension dicitonary // just because e.g. the spellchecker is not asked what // languages it does support currently... // Since the check is on-demand occuring and executed once it should // not be too troublesome. // In OOo 3.0 we will not need the respective code anymore at all. // aAny <<= nCurrentDataFilesChangedCheckValue; aAny <<= (sal_Int32) -1; // keep the value set to 'need to check' Further testing unfortunately reveals that it applies to current builds, too (despite saying "builds until OOo 3.0"). So if you use "aAny <<= nCurrentDataFilesChangedCheckValue", newly installed dictionary extentions will not be recognized until you restart LO. By "not recognized" I mean that the checkmarks do not appear on the language in the language drop down. Another potential solution for the original problem might be in lngsvcmgr.cxx, LngSvcMgr::getAvailableServices(). It says: // don't used cached data here (force re-evaluation in order to have downloaded dictionaries // already found without the need to restart the office delete pAvailGrammarSvcs; pAvailGrammarSvcs = 0; Commenting out that line makes SvxLinguConfigUpdate::UpdateAll() quite fast so the original problem is gone. Grammar checkers need a restart of LO anyway, so I think the cache could be used here. Trying to debug this issue, I also found you can solve it by just commenting out (*pLayIter)->GetCurrShell()->LayoutIdle(); in doclay.cxx in the if (pTmpRoot->IsNeedGrammarCheck()) block. That code was committed on 2010-06-13. As I'm just debugging and I don't know much about LO internals I have no idea what the side effects of removing that code might be, but everything worked fine for me at a first glance. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/8 ------------------------------------------------------------------------ On 2012-05-11T19:48:41+00:00 Michael Meeks wrote: > I also found you can solve it by just commenting out > (*pLayIter)->GetCurrShell()->LayoutIdle(); in doclay.cxx in > the if (pTmpRoot->IsNeedGrammarCheck()) block. I poked at that - it seems that just disables the execution of the idle handlers one of which loads the checker; so - I'm more interested in the lower level pieces you identify :-) digging there currently ... Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/9 ------------------------------------------------------------------------ On 2012-05-14T12:35:01+00:00 Michael Meeks wrote: More debugging - it -seems- that part of our problem is that we install dictionaries (etc.) for a ton of languages, which then in turn provokes all this silliness in editeng :-) Having said that - there really seems like no excuse for not using the cache there - the original commit commenting out that stuff read: INTEGRATION: CWS oolinguforso (1.25.18); FILE MERGED 2006/12/18 09:23:06 tl 1.25.18.4: #130176# have OOo download dictionaries functional without restart But the issue is an obsolete / internal Sun bug ticket which we have no access to now; testing this download/install dictionaries and making that work nicely seems a bit of a royal pain as well. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/17 ------------------------------------------------------------------------ On 2012-05-14T13:48:27+00:00 Libreoffice-bugs wrote: Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8924a7bde1bd5ddb857342b6f8704c250f897078 fdo#35270 - enable caching of grammar checker properties Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/18 ------------------------------------------------------------------------ On 2012-05-14T16:29:00+00:00 Michael Meeks wrote: I'll knock up an easy-hack to fix the tangled awfulness that is the editeng / linguistic interaction in a bit :-) Thanks so much for looking into this Daniel ! it's in the review queue for 3.5.4 (rc1 due next week). Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/19 ------------------------------------------------------------------------ On 2012-05-15T09:55:55+00:00 Libreoffice-bugs wrote: Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ecc734f631ce4597782b17b071752b8fa223d49&g=libreoffice-3-5 fdo#35270 - enable caching of grammar checker properties It will be available in LibreOffice 3.5.4. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/998778/comments/21 ** Changed in: df-libreoffice Status: Unknown => Fix Released ** Changed in: df-libreoffice Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/998778 Title: [Upstream] openjdk-7 slows LibreOffice a lot and causes it to crash Status in LibreOffice Productivity Suite: Fix Released Status in “libreoffice” package in Ubuntu: New Bug description: openjdk-7 slows LibreOffice (LO) a lot and causes it to freeze/ hang very frequently. LO boots in seconds when openjdk-7 is not used. LO is very stable & does not hang when openjdk-7 is not used. I did not have any problems with LO in the previous version of Ubuntu (11.10). Unfortunately, I cannot 'live' without openjdk-7 as it is needed in some LO extensions that I used every single day. For example, LanguageTool & OpenOffice.org2GoogleDocs. I have attached some error logs. Ubuntu Release 12.04 (precise) 32-bit Kernel Linux 3.2.0-24-generic-pae LibreOffice 3.5.3.2 Build ID: 350m1(Build:2) WORKAROUND: openjdk-6 [JRE 1.6.0_24 (Sun Microsystems Inc.)] & found that LO is not that slow & it has not crashed yet. To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/998778/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
