This is a new bug in 5.2.4.1 that only affects Writer. Only tested in Windows 7, (un)confirmation in Linux needed. Start Writer, open Tools menu. It takes a few seconds to open for the first time. Other menus come up instantly. Occurs both with default and OpenGL rendering.
Does not occur with 5.4 daily build (2016-12-02_00:57:58), 5.3beta1, 5.3 daily build (2016-11-17_00:29:08), but occurs with 5.3alpha1 in Windows 7. Couldn't reproduce it with 5.3alpha1 / Ubuntu 16.04. Luke, raal, could either of you confirm and bibisect/reverse bibisect this in Windows, so the fix can be backported in 5.2.4.2?
28921247e97e0a89c0ff45676835978179750e6e is the first bad commit commit 28921247e97e0a89c0ff45676835978179750e6e Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Jul 12 05:10:54 2015 -0700 source 6c189a1eb90012789692344aa7dc418c7ec7f032 source 6c189a1eb90012789692344aa7dc418c7ec7f032 # bad: [05d11632892a322664fb52bac90b2598b7fb7544] source 5616d22b57a9a5e57d545e912e029162a230829b # good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65 git bisect start '05d11632892a322664fb52bac90b2598b7fb7544' 'oldest' # bad: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source 4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f git bisect bad 97526ab777da7e58ce283c05498262ecdd4d6f7f # bad: [2202cdaa0eae3f646f1285a0ea45934edeb26e8a] source a88bf8fd10c42a15e5d6e66da656889c82b4933a git bisect bad 2202cdaa0eae3f646f1285a0ea45934edeb26e8a # bad: [1d0a95445c203c11beb1aa5eae844cf178ea0984] source 8f324aebfb94c4b2023894121b954ad4f35eb395 git bisect bad 1d0a95445c203c11beb1aa5eae844cf178ea0984 # bad: [fb2523235c0a0c37d4e1f482afde48066f2c4b83] source 5b87ff40857147bee697a9bf420aae89e8cd9e93 git bisect bad fb2523235c0a0c37d4e1f482afde48066f2c4b83 # good: [f01d28277d2e35de86331eebe5e3af87add50501] source a570e3070943845d3e52c1d0cd406b1a530bf0c4 git bisect good f01d28277d2e35de86331eebe5e3af87add50501 # good: [97aa480c7be34fcd095e064f3980c8c265cc2842] source b33972b61401da79aadbb98d486eec5c285b5946 git bisect good 97aa480c7be34fcd095e064f3980c8c265cc2842 # bad: [da34afe1bb90a59f3848950d44cce2888efe6990] source 9509ce61031f27dd1977599ffc271aaffdb6ca82 git bisect bad da34afe1bb90a59f3848950d44cce2888efe6990 # bad: [804c31cae6a1d1cbb7216b36e68b4e0706315fc3] source bd2f71fc265d5bf7a6b490a49549c1233d4bdc4d git bisect bad 804c31cae6a1d1cbb7216b36e68b4e0706315fc3 # good: [9508b848782a23d5d3dd81df8f45dced8b60909d] source ac52b11a150cd260cfb58aa3013abcf499d04468 git bisect good 9508b848782a23d5d3dd81df8f45dced8b60909d # bad: [5ae27366d0a75b2cfc65d61b43598dec6753dd72] source 8fa5e036f59eea1413c66dccb44b8f4ecb8deb09 git bisect bad 5ae27366d0a75b2cfc65d61b43598dec6753dd72 # bad: [9577d16868c8dd499ce6950feb53b17dca515537] source f18096f1b5cce12033e6721fa6624f02e797acc3 git bisect bad 9577d16868c8dd499ce6950feb53b17dca515537 # good: [f84557d06f5e17d1f467a077cf91d3e438636328] source 778d5508f5be8d9e31e1634110137f8afdf0065e git bisect good f84557d06f5e17d1f467a077cf91d3e438636328 # bad: [28921247e97e0a89c0ff45676835978179750e6e] source 6c189a1eb90012789692344aa7dc418c7ec7f032 git bisect bad 28921247e97e0a89c0ff45676835978179750e6e # first bad commit: [28921247e97e0a89c0ff45676835978179750e6e] source 6c189a1eb90012789692344aa7dc418c7ec7f032
As it turns out, this isn't a new issue at all, but only occurs if a lot of dictionary extensions are installed. The reason why I could reproduce in some versions and not others is that the SI-GUI installed pre-release/release versions had all dictionaries, while master builds and normally installed versions didn't (like 5.3beta1 was in my case). Still a regression, but from 5.1, and from the commit below. Adding Cc: to Yousuf Philips. Not sure which part of the commit causes the performance issue. https://cgit.freedesktop.org/libreoffice/core/commit/?id=6c189a1eb90012789692344aa7dc418c7ec7f032 "tdf#91781 Reorganize writer's menu bar"
No clue Aron what could be the cause, but with my patch i moved a few entries from submenus into the main Tools menu, so try testing deleting those entries below. .uno:ThesaurusDialog .uno:EditGlossary
Moving it to NEW as the problematic commit has been identified
(In reply to Aron Budea from comment #1) > Does not occur with 5.4 daily build (2016-12-02_00:57:58), 5.3beta1, 5.3 > daily build (2016-11-17_00:29:08), but occurs with 5.3alpha1 in Windows 7. > > Couldn't reproduce it with 5.3alpha1 / Ubuntu 16.04. As it doesnt happen in master and 5.3 (fresh), is there something that needs to be fixed?
(In reply to Yousuf Philips (jay) from comment #6) > As it doesnt happen in master and 5.3 (fresh), is there something that needs > to be fixed? It still happens, see the first paragraph in comment 3 for details. I checked a bit, and it seems Thesaurus is causing the stall (thanks for the hint), but I didn't have the time to further experiment with it. What I did, I tried earlier versions, and the stall happened when I entered that particular submenu.
*** Bug 105439 has been marked as a duplicate of this bug. ***
Setting to all. Same issue on MacOS Version: 5.4.0.0.alpha0+ Build ID: ae0a317c20110ade8b9eaef3ecbd2c5781303649 CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-01-21_01:02:06 Locale: nl-NL (nl_NL.UTF-8); Calc: group Also the right-click menu is affected (bug 105439)
Created attachment 130873 [details] Process Monitor Output LO5400 It's seems to be caused by cycling through lots of directory's (over and over again). I have added a process monitor output when clicking on Menu Tools in Writer immediately after launch. It's nearly the same as bug 104637 (it actually still exists) and has similarity's with bug 104582 Version: 5.4.0.0.alpha0+ Build ID: 2670ca3fc597decae78499d1397539668eb84e5e CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-31_05:32:46 Locale: nl-NL (nl_NL); Calc: CL
@Aron: As the thesaurus is available in a submenu prior to 5.1, i would check earlier versions to see if the same problem happens when opening the Tools > Language submenu, as this problem is likely inherited from OOo. @Maxim, @Michael: Any thoughts?
Created attachment 131399 [details] Xcode Time Profile
Created attachment 131400 [details] LLDB backtrace Version: 5.4.0.0.alpha0+ Build ID: 273823de644f2086377795d3afb51a39d30bfeaa CPU Threads: 4; OS Version: Mac OS X 10.12.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
*** Bug 108698 has been marked as a duplicate of this bug. ***
Let's remove the regression-related keywords, as it's not a really a regression. Linking Telesto's process monitor output from the other thread: attachment 134214 [details].
1. Comment 15 is obsolete: A full process Monitor output is already attached 2. There seem to be two issues combined here: 2.a disk queries related to python (bug 108698 (added as duplicate to this one) 2.b disk queries related to louno.ini (bug 108645) -> probably the main cause of the lag
This seems to be related to bug 108468, as both deal with some kind of language component initialization, though not entirely the same: - if first the user types, and then opens Tools menu, LO only stalls once, - if first the user opens Tools menu, and then types, LO stalls both times. I'd assume preloading the language components would solve this issue as well.
Created attachment 136240 [details] Xcode instruments allocations and BT It's possible that the slowness is somehow caused while reading a xml file with liblangtag. 0 libsystem_malloc.dylib malloc_zone_malloc 1 libsystem_malloc.dylib malloc 2 libxml2.2.dylib xmlStrndup 3 libxml2.2.dylib xmlSAX2TextNode 4 libxml2.2.dylib xmlSAX2Characters 5 libxml2.2.dylib xmlParseCharData 6 libxml2.2.dylib xmlParseContent 7 libxml2.2.dylib xmlParseElement 8 libxml2.2.dylib xmlParseContent 9 libxml2.2.dylib xmlParseElement 10 libxml2.2.dylib xmlParseContent 11 libxml2.2.dylib xmlParseElement 12 libxml2.2.dylib xmlParseDocument 13 libxml2.2.dylib xmlDoRead 14 liblangtag.1.dylib lt_xml_read_subtag_registry /Users/demo/lode/dev/core/workdir/UnpackedTarball/langtag/liblangtag/lt-xml.c:86 15 liblangtag.1.dylib lt_xml_get_subtag_registry /Users/demo/lode/dev/core/workdir/UnpackedTarball/langtag/liblangtag/lt-xml.c:362
Eike is the liblangtag man - and of course, we do read this large file =) I wonder - if we could do that in a thread after startup or something (?)
No repro in: Version: 6.0.0.0.alpha0+ Build ID: e038dfdf05096edc0e9c38c9a686b5d23ba39352 CPU threads: 4; OS: Windows 6.29; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-09-14_23:31:01 Locale: nl-NL (nl_NL); Calc: CL only a small delay (1 or sec) Version: 6.0.0.0.alpha0+ Build ID: e038dfdf05096edc0e9c38c9a686b5d23ba39352 CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-09-14_23:35:41 Locale: nl-NL (nl_NL.UTF-8); Calc: group Please backport =). Probably: https://cgit.freedesktop.org/libreoffice/core/commit/?id=61037c622b13122de578f5ef60a3b343af3f9633 (based on the lt_xml_read_subtag_registry screenshots)
Related: https://gerrit.libreoffice.org/#/c/56095/ Quote from Tor Lillqvist; Patch Set 6: The Right Way to fix the problem would of course be to re-work the code path that is taking so long; why does the code insist on initialising (in some sense) stuff for languages not even used at the moment? Adding debugging printout in various places one sees that LngSvcMgr::getAvailableServices() is called for all potential language/locale combinations. Why? And org.libreoffice.comp.pyuno.Lightproof.pt_BR, org.libreoffice.comp.pyuno.Lightproof.ru_RU, etc even if no document with text in Brazi.ian Portuguese or Rssian os nowhere open. Etc. My God, it's full of crap.
I have been looking at the delay after typing the first character in Writer in a LO session. Seeing this requires having a LO built with --with-myspell-dicts (for typical developers, no idea what it requires for people using end-user packages). It is the LightProof Python code that causes most of the slowness. Here is the "Heaviest Stack Trace" from the TimeProfiler tool in Intruments on macOS, slightly edited. The number after the dylib name is in milliseconds. One can see that the first call to pyuno::Adapter::invoke() takes about 300 ms. (And some temporary SAL_DEBUG output confirms.) > libdyld.dylib 803.0 start > soffice 803.0 main /Users/tml/lo/xxx/desktop/source/app/main.c:47 > libsofficeapp.dylib 803.0 soffice_main /Users/tml/lo/xxx/desktop/source/app/sofficemain.cxx:167 > libvcllo.dylib 803.0 SVMain() /Users/tml/lo/xxx/vcl/source/app/svmain.cxx:233 > libvcllo.dylib 803.0 ImplSVMainHook(int*) /Users/tml/lo/xxx/vcl/osx/salinst.cxx:225 > AppKit 803.0 NSApplicationMain > AppKit 803.0 -[NSApplication run] > libvcllo.dylib 803.0 -[VCL_NSApplication sendEvent:] /Users/tml/lo/xxx/vcl/osx/vclnsapp.mm:101 > libvcllo.dylib 803.0 AquaSalInstance::handleAppDefinedEvent(NSEvent*) /Users/tml/lo/xxx/vcl/osx/salinst.cxx:463 > libvcllo.dylib 803.0 ImplSVMain() /Users/tml/lo/xxx/vcl/source/app/svmain.cxx:198 > libsofficeapp.dylib 803.0 desktop::Desktop::Main() /Users/tml/lo/xxx/desktop/source/app/app.cxx:1641 > libvcllo.dylib 803.0 Application::Execute() /Users/tml/lo/xxx/vcl/source/app/svapp.cxx:449 > libvcllo.dylib 803.0 ImplYield(bool, bool) /Users/tml/lo/xxx/vcl/source/app/svapp.cxx:469 > libvcllo.dylib 803.0 AquaSalInstance::DoYield(bool, bool) /Users/tml/lo/xxx/vcl/osx/salinst.cxx:628 > libvcllo.dylib 601.0 AquaSalTimer::callTimerCallback() /Users/tml/lo/xxx/vcl/osx/saltimer.cxx:146 > libvcllo.dylib 601.0 Scheduler::ProcessTaskScheduling() /Users/tml/lo/xxx/vcl/source/app/scheduler.cxx:447 > libswlo.dylib 597.0 sw::DocumentTimerManager::DoIdleJobs(Timer*) /Users/tml/lo/xxx/sw/source/core/doc/DocumentTimerManager.cxx:146 > libswlo.dylib 597.0 SwViewShell::LayoutIdle() /Users/tml/lo/xxx/sw/source/core/view/viewsh.cxx:711 > libswlo.dylib 597.0 SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) /Users/tml/lo/xxx/sw/source/core/layout/layact.cxx:2097 > libswlo.dylib 597.0 SwLayIdle::DoIdleJob(SwLayIdle::IdleJobType, bool) /Users/tml/lo/xxx/sw/source/core/layout/layact.cxx:2009 > libswlo.dylib 597.0 SwLayIdle::DoIdleJob_(SwContentFrame const*, SwLayIdle::IdleJobType) /Users/tml/lo/xxx/sw/source/core/layout/layact.cxx:1891 > libswlo.dylib 595.0 SwTextFrame::AutoSpell_(SwContentNode const*, int) /Users/tml/lo/xxx/sw/source/core/txtnode/txtedt.cxx:1330 > libswlo.dylib 533.0 SwModule::CreateLngSvcEvtListener() /Users/tml/lo/xxx/sw/source/uibase/app/swmodule.cxx:233 > libswlo.dylib 533.0 SwLinguServiceEventListener::SwLinguServiceEventListener() /Users/tml/lo/xxx/sw/source/uibase/uno/dlelstnr.cxx:51 > libswlo.dylib 533.0 com::sun::star::linguistic2::LinguServiceManager::create(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/linguistic2/LinguServiceManager.hpp:38 > libuno_cppuhelpergcc3.dylib.3 533.0 non-virtual thunk to cppuhelper::ServiceManager::createInstanceWithContext(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:0 > libuno_cppuhelpergcc3.dylib.3 533.0 cppuhelper::ServiceManager::createInstanceWithContext(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:991 > libuno_cppuhelpergcc3.dylib.3 533.0 cppuhelper::ServiceManager::Data::Implementation::createInstance(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:667 > libuno_cppuhelpergcc3.dylib.3 533.0 non-virtual thunk to cppu::OFactoryComponentHelper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:0 > libuno_cppuhelpergcc3.dylib.3 533.0 cppu::OFactoryComponentHelper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:374 > libuno_cppuhelpergcc3.dylib.3 533.0 cppu::OSingleFactoryHelper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:175 > libuno_cppuhelpergcc3.dylib.3 533.0 cppu::OSingleFactoryHelper::createInstanceEveryTime(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/factory.cxx:149 > liblnglo.dylib 533.0 LngSvcMgr_CreateInstance(com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const&) /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:1980 > liblnglo.dylib 533.0 LngSvcMgr::LngSvcMgr() /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:438 > liblnglo.dylib 533.0 LngSvcMgr::UpdateAll() /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:664 > liblnglo.dylib 414.0 LngSvcMgr::getAvailableServices(rtl::OUString const&, com::sun::star::lang::Locale const&) /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:1500 > liblnglo.dylib 313.0 LngSvcMgr::GetAvailableGrammarSvcs_Impl() /Users/tml/lo/xxx/linguistic/source/lngsvcmgr.cxx:1088 > libuno_cppuhelpergcc3.dylib.3 311.0 non-virtual thunk to (anonymous namespace)::ImplementationWrapper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:0 > libuno_cppuhelpergcc3.dylib.3 311.0 (anonymous namespace)::ImplementationWrapper::createInstanceWithContext(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:587 > libuno_cppuhelpergcc3.dylib.3 306.0 cppuhelper::ServiceManager::loadImplementation(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, std::__1::shared_ptr<cppuhelper::ServiceManager::Data::Implementation> const&) /Users/tml/lo/xxx/cppuhelper/source/servicemanager.cxx:815 > libgcc3_uno.dylib 306.0 privateSnippetExecutor /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/call.cxx:27 > libgcc3_uno.dylib 306.0 cpp_vtable_call /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/cpp2uno.cxx:374 > libgcc3_uno.dylib 306.0 cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/cpp2uno.cxx:187 > libinvocadaptlo.dylib 306.0 stoc_invadp::AdapterImpl::invoke(_typelib_TypeDescription const*, void*, void**, _uno_Any**) /Users/tml/lo/xxx/stoc/source/invocation_adapterfactory/iafactory.cxx:466 > libgcc3_uno.dylib 306.0 bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/uno2cpp.cxx:0 > libgcc3_uno.dylib 306.0 cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/uno2cpp.cxx:233 > libgcc3_uno.dylib 306.0 gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) /Users/tml/lo/xxx/bridges/source/cpp_uno/gcc3_macosx_x86-64/callvirtualmethod.cxx:77 > libpyuno.dylib 306.0 non-virtual thunk to pyuno::Adapter::invoke(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Sequence<short>&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /Users/tml/lo/xxx/pyuno/source/module/pyuno_adapter.cxx:0 > libpyuno.dylib 306.0 pyuno::Adapter::invoke(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Sequence<short>&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) /Users/tml/lo/xxx/pyuno/source/module/pyuno_adapter.cxx:250
Corresponding SAL_DEBUG output, not from the exact same run, so the timing is a bit different, here the interesting bit takes over half a second, probably because I had a build ongoing at the same time: > 0.000:debug:29870:36165630: >> pyuno::Adapter::invoke(activate,4) > 0.020:debug:29870:36165630: << pyuno::Adapter::invoke() > 0.020:debug:29870:36165630: >> pyuno::Adapter::invoke(createInstanceWithContext,1) > 0.045:debug:29870:36165630: << pyuno::Adapter::invoke() > 0.046:debug:29870:36165630: >> pyuno::Adapter::invoke(hasLocale,1) > 0.046:debug:29870:36165630: << pyuno::Adapter::invoke() > 0.046:debug:29870:36165630: >> pyuno::Adapter::invoke(doProofreading,6) > 0.101:debug:29870:36165630: << pyuno::Adapter::invoke() > 0.741:debug:29870:36165479: >> LngSvcMgr::UpdateAll() > 0.742:debug:29870:36165479: LngSvcMgr::UpdateAll() 697 'com.sun.star.linguistic2.SpellChecker' nNodeNames=140 > 0.820:debug:29870:36165479: >> MacSpellChecker::getLocales() > 0.840:debug:29870:36165479: MacSpellChecker::getLocales(): count=22 > 0.840:debug:29870:36165479: << MacSpellChecker::getLocales() > 0.889:debug:29870:36165479: >> MacSpellChecker::getLocales() > 0.889:debug:29870:36165479: << MacSpellChecker::getLocales() > 0.889:debug:29870:36165479: LngSvcMgr::UpdateAll() 717 nAvailLocales=140 > 0.936:debug:29870:36165479: LngSvcMgr::UpdateAll() 697 'com.sun.star.linguistic2.Proofreader' nNodeNames=19 > 0.937:debug:29870:36165479: >> LngSvcMgr::GetAvailableGrammarSvcs_Impl() > 0.937:debug:29870:36165479: >> pyuno::Adapter::invoke(activate,4) > 0.940:debug:29870:36165479: Lightproof.py HEAD > 0.940:debug:29870:36165479: = 2 > 0.940:debug:29870:36165479: = 3 > 1.598:debug:29870:36165479: = 4 > 1.598:debug:29870:36165479: = 5 > 1.599:debug:29870:36165479: = 6 > 1.599:debug:29870:36165479: = 7 > 1.601:debug:29870:36165479: = 8 > 1.602:debug:29870:36165479: << pyuno::Adapter::invoke() The Lightproof.py line and the following lines "== 2" etc are from instdir/LibreOffice.app/Contents/Resources/extensions/dict-pt-BR/Lightproof.py, where I added some pyuno.sal_debug() calls (an upcoming enhancement, soon in gerrit): > # Lightproof grammar checker for LibreOffice and OpenOffice.org > # 2009-2012 (c) Laszlo Nemeth (nemeth at numbertext org), license: MPL 1.1 / GPLv3+ / LGPLv3+ > > import pyuno > pyuno.sal_debug('Lightproof.py HEAD') > pyuno.sal_debug('= 2') > import uno, unohelper, os, sys, traceback > pyuno.sal_debug('= 3') > from lightproof_impl_pt_BR import locales > pyuno.sal_debug('= 4') > from lightproof_impl_pt_BR import pkg > pyuno.sal_debug('= 5') > import lightproof_impl_pt_BR > pyuno.sal_debug('= 6') > import lightproof_handler_pt_BR > pyuno.sal_debug('= 7') > I.e. it is clear that the thing that takes lots of time is loading the lightproof_impl_pt_BR Python module. Even if what is done at this stage is just getting a list of locales that we have proofreaders for. The lightproof_impl_pt_BR module is *huge* (it has the actual data for pt-BR for Lightproof). And note that there isn't even any document with text in pt-BR open in LibreOffice... So it is totally unnecessary to waste CPU time on loading that data. The Lightproof code needs to be reorganised so that the heavy data modules are loaded only when actually needed.
@Tor Lillqvist Is this related to Lightproof.py or is there maybe some issue with Python itself? DrMemory (on windows) reported quite some UNADDRESSABLE ACCESS beyond heap bounds errors for python35.dll (bug 108270 comment 7)
Lightproof uses lazy loading by using __import__ for the compiled rules, but not for the extra Python codes defined in [code] parts of the grammar rule file. In fact, that I was intended for small extra functions, not a full Python grammar checker, so I didn't optimize it. The good news, that the smaller file is the problem here: :) laci@nemeth:~/libreoffice/dictionaries/pt_BR/pythonpath$ ls -lS -rw-rw-r-- 1 laci laci 4805925 nov 23 2017 lightproof_pt_BR.py -rw-rw-r-- 1 laci laci 1491297 nov 23 2017 lightproof_impl_pt_BR.py Thanks for your report and research. I will check it.
Suggested fix in https://gerrit.libreoffice.org/#/c/56176/ But if you Lászlo are working on a better fix, even better.
I am not a Python programmer and it probably shows;)
(In reply to Tor Lillqvist from comment #27) > I am not a Python programmer and it probably shows;) Tor, you are a better Python programmer, than me. :) Many thanks for solving this issue! I will port your solution to the Lightproof framework (https://cgit.freedesktop.org/libreoffice/lightproof/), too.
I must confess I have no idea how to check whether the pt-BR Lightproof works any longer after my change... Anybody? The lightproof_impl_pt_BR.py and lightproof_pt_BR.py files are rather hard to understand. (I did try an equivalent change to the en Lightproof.py and that didn't break it. But it would be nice to be able to double-check for pt-BR.)
(In reply to Tor Lillqvist from comment #29) > I must confess I have no idea how to check whether the pt-BR Lightproof > works any longer after my change... Anybody? The lightproof_impl_pt_BR.py > and lightproof_pt_BR.py files are rather hard to understand. > > (I did try an equivalent change to the en Lightproof.py and that didn't > break it. But it would be nice to be able to double-check for pt-BR.) It seems, a lower case sentence starting word, ie. "uno" will be underlined by the pt-BR grammar checker. I started to check, there is a problem with the patch yet. I will fix tomorrow, if it's ok: Python exception: <class 'AttributeError'>: module 'lightproof_impl_pt_BR' has no attribute 'SMGR', traceback follows File "/home/laci/libreoffice/instdir/share/extensions/dict-pt-BR/Lightproof.py", line 67, in doProofreading if lightproof_impl_pt_BR.SMGR == None:
Ah! Yes, I forgot that thing. I guess in lightproof_impl_pt_BR.py , there needs to be: > calcfunc = None > > +SMGR = None > > # check settings That's what I did when I first experimented with the smaller lightproof for en, but I forgot with pt_BR. I also now see that in pt_BR/Lightproof.py I accidentally use lightproof_impl_en.SMGR.createInstanceWithContext("com.sun.star.linguistic2.SpellChecker", currentContext) ... Will fix.
https://gerrit.libreoffice.org/#/c/56217/ should fix it.
(In reply to Tor Lillqvist from comment #32) > https://gerrit.libreoffice.org/#/c/56217/ should fix it. I've checked it, it did. Thanks, Tor!
Could somebody please check if the fix to the pt-BR Lightproof helped also for the thing the initial comment actually is about?
Aron, do you think this is fixed now?
No repro for me :-) Version: 6.2.0.0.alpha0+ Build ID: e7d3976cb80f7e7401be071f905a764dd6cb4d6e CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-29_04:46:32 Locale: nl-NL (nl_NL); Calc: CL
I checked with 6.1.0.1, and the Tools menu opens a lot quicker, albeit still not instantly (for the first time) like the other menus. I'd say that's fine, but to be sure, I'll check again with 6.1.0.2, and also with dictionaries copied to a daily build (I don't have a complete master build including dictionaries, but all relevant dictionary changes have been cherry-picked to 6.1, anyway). Thanks for the fixes, Tor! Commits in master: https://cgit.freedesktop.org/libreoffice/dictionaries/commit/?id=2d8dd0af877de8494ca9c2c027eba4a42bbc09eb https://cgit.freedesktop.org/libreoffice/dictionaries/commit/?id=846e5da4b28bb40158cfb992f3a371614e25a349 https://cgit.freedesktop.org/libreoffice/dictionaries/commit/?id=fe72d24920c8a4dcbee18925cb19e6b6625f6553 In 6.1 (one of them contains the changes from two master commits): https://cgit.freedesktop.org/libreoffice/dictionaries/commit/?h=libreoffice-6-1&id=d401ecde39ee763e1d28c8850c3eb6fb628d29c3 https://cgit.freedesktop.org/libreoffice/dictionaries/commit/?h=libreoffice-6-1&id=3b6db3f228458fa2b2f9911716b95ed0d632c9ce
And the missing piece is this commit, also by Tor: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f1d9aca4bf596c0a3be44483b1d60867f12683ec Tor, would it be possible to get this into libreoffice-6-1 and libreoffice-6-1-0?
Is the commit you refer to important enough to get into 6.1? I thought only clear bug fixes were supposed to be cherry-picked. That commit is not a such.
Depends how big and risky it is I guess.