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.
Hi szotsaki, would you attach the file caused the problem? I didn't see this issue in my environment.
Ah, just realized may be the language tool causes the issue, how about the performance after removing languagetool packages? Thanks!
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.
[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
needinfo keyword redundant by needinfo status.
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.
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.
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.
> 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 ...
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.
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
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).
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.