Description: If there are many LanguagePacks and/or Dictionaries installed, the start of LibO gets really slow. This can be easily noticed when using the LibO Separate Install Gui. In the Admin.Install, which the tool does, all existing LanguagePacks, AutoCorr and Dictionaries that exist in the installer are copied to the Program-Destination. If I start one of those LibO Versions (as done regularly for testing), there is a 1 to 2 seconds "delay" until something happens on screen. If I delete all the unneeded stuff, LibO starts without any noticeable delay. Of course one can argument, that having so many LanguagePacks and Dictionaries is not a common installation scenario, but I think that this can also have some impact on regular installs. So maybe its worth it to cleanup the LibO boot-process? I think that LibO checks what LangPacks are "installed" on EVERY instance-start (even if quickstarter is allready running!). I dont know exatly what happens in background, but it seems like this: User clicks LibO -> LibO checks every LangPack/AutoCorr/Dictionary that is installed for whatever reason -> Gui starts. Why not handle it this way instead: User clicks LibO -> Preferencs are read -> if Gui-Language is defined, use check only THIS LangPack -> user LangPack -> start GUI. At this point, AutoCorr/Dictionaries doesn't even have to be touched (sorry, if this is allready the case, as said, I don't know the current-boot-process). Don't get me wrong, I think if its installed well, current LibO Versions have a good start time. But faster is always better. I already saw people arguing, that LibO is so slow and MS Office is so much faster bla bla. Even though this isn't true (I did some comparisons lately), every possibility to speedup start should be taken into consideration. Steps to Reproduce: 1. Do a "admin Install" of LibO or just install lots of LangPacks and Dictionaries on Install 2. Start LibO 3. Actual Results: There is a very noticeable delay until window/Spashscreen appears. Expected Results: There should be no delay no matter how many LangPacks/Dictionaries are installed. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info:
Hello, LibreOffice 6.2.2.2 is going to be released today, could you please try again with this version to see if the problem has been resolved meanwhile? Thanks in advance
Hello Xisco, Sorry for the late reply... Just tested 6.2.3.2 and the performance issue still exists.
Could you please paste the info from Help - about LibreOffice ?
Version: 6.2.3.2 Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU-Threads: 12; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-AT (de_AT); UI-Sprache: de-DE Calc: CL
[Automated Action] NeedInfo-To-Unconfirmed
Could you please be more precise and inditate how many dictionaries you have installed at the same time and which ones ?
(In reply to Xisco Faulí from comment #6) > Could you please be more precise and inditate how many dictionaries you have > installed at the same time and which ones ? As noted in my initial report: "This can be easily noticed when using the LibO Separate Install Gui. In the Admin-Install, which the tool does, ALL EXISTING LanguagePacks, AutoCorr and Dictionaries that exist in the installer are copied to the Program-Destination." But to give you the numbers you wanted: (these numbers are from the test-install that is made with "Separate Install Gui". Of course this is NOT the amount of languages I have installed in my regular setup.) Dictionaries: 51 dict-af dict-an dict-ar dict-be dict-bg dict-bn dict-bo dict-br dict-bs dict-ca dict-cs dict-da dict-de dict-el dict-en dict-es dict-et dict-fr dict-gd dict-gl dict-gu dict-he dict-hi dict-hr dict-hu dict-id dict-is dict-it dict-lo dict-lt dict-lv dict-ne dict-nl dict-no dict-oc dict-pl dict-pt-BR dict-pt-PT dict-ro dict-ru dict-si dict-sk dict-sl dict-sq dict-sr dict-sv dict-te dict-th dict-uk dict-vi dict-zu Lang-Packs: 117 fcfg_langpack_af.xcd fcfg_langpack_am.xcd fcfg_langpack_ar.xcd fcfg_langpack_as.xcd fcfg_langpack_ast.xcd fcfg_langpack_be.xcd fcfg_langpack_bg.xcd fcfg_langpack_bn-IN.xcd fcfg_langpack_bn.xcd fcfg_langpack_bo.xcd fcfg_langpack_br.xcd fcfg_langpack_brx.xcd fcfg_langpack_bs.xcd fcfg_langpack_ca-valencia.x fcfg_langpack_ca.xcd fcfg_langpack_cs.xcd fcfg_langpack_cy.xcd fcfg_langpack_da.xcd fcfg_langpack_de.xcd fcfg_langpack_dgo.xcd fcfg_langpack_dsb.xcd fcfg_langpack_dz.xcd fcfg_langpack_el.xcd fcfg_langpack_en-GB.xcd fcfg_langpack_en-US.xcd fcfg_langpack_en-ZA.xcd fcfg_langpack_eo.xcd fcfg_langpack_es.xcd fcfg_langpack_et.xcd fcfg_langpack_eu.xcd fcfg_langpack_fa.xcd fcfg_langpack_fi.xcd fcfg_langpack_fr.xcd fcfg_langpack_fy.xcd fcfg_langpack_ga.xcd fcfg_langpack_gd.xcd fcfg_langpack_gl.xcd fcfg_langpack_gu.xcd fcfg_langpack_gug.xcd fcfg_langpack_he.xcd fcfg_langpack_hi.xcd fcfg_langpack_hr.xcd fcfg_langpack_hsb.xcd fcfg_langpack_hu.xcd fcfg_langpack_id.xcd fcfg_langpack_is.xcd fcfg_langpack_it.xcd fcfg_langpack_ja.xcd fcfg_langpack_ka.xcd fcfg_langpack_kab.xcd fcfg_langpack_kk.xcd fcfg_langpack_km.xcd fcfg_langpack_kmr-Latn.xcd fcfg_langpack_kn.xcd fcfg_langpack_ko.xcd fcfg_langpack_kok.xcd fcfg_langpack_ks.xcd fcfg_langpack_lb.xcd fcfg_langpack_lo.xcd fcfg_langpack_lt.xcd fcfg_langpack_lv.xcd fcfg_langpack_mai.xcd fcfg_langpack_mk.xcd fcfg_langpack_ml.xcd fcfg_langpack_mn.xcd fcfg_langpack_mni.xcd fcfg_langpack_mr.xcd fcfg_langpack_my.xcd fcfg_langpack_nb.xcd fcfg_langpack_ne.xcd fcfg_langpack_nl.xcd fcfg_langpack_nn.xcd fcfg_langpack_nr.xcd fcfg_langpack_nso.xcd fcfg_langpack_oc.xcd fcfg_langpack_om.xcd fcfg_langpack_or.xcd fcfg_langpack_pa-IN.xcd fcfg_langpack_pl.xcd fcfg_langpack_pt-BR.xcd fcfg_langpack_pt.xcd fcfg_langpack_qtz.xcd fcfg_langpack_ro.xcd fcfg_langpack_ru.xcd fcfg_langpack_rw.xcd fcfg_langpack_sa-IN.xcd fcfg_langpack_sat.xcd fcfg_langpack_sd.xcd fcfg_langpack_si.xcd fcfg_langpack_sid.xcd fcfg_langpack_sk.xcd fcfg_langpack_sl.xcd fcfg_langpack_sq.xcd fcfg_langpack_sr-Latn.xcd fcfg_langpack_sr.xcd fcfg_langpack_ss.xcd fcfg_langpack_st.xcd fcfg_langpack_sv.xcd fcfg_langpack_sw-TZ.xcd fcfg_langpack_ta.xcd fcfg_langpack_te.xcd fcfg_langpack_tg.xcd fcfg_langpack_th.xcd fcfg_langpack_tn.xcd fcfg_langpack_tr.xcd fcfg_langpack_ts.xcd fcfg_langpack_tt.xcd fcfg_langpack_ug.xcd fcfg_langpack_uk.xcd fcfg_langpack_uz.xcd fcfg_langpack_ve.xcd fcfg_langpack_vec.xcd fcfg_langpack_vi.xcd fcfg_langpack_xh.xcd fcfg_langpack_zh-CN.xcd fcfg_langpack_zh-TW.xcd fcfg_langpack_zu.xcd AutoCorrection: 47 acor_af-ZA.dat acor_bg-BG.dat acor_ca-ES.dat acor_cs-CZ.dat acor_da-DK.dat acor_de.dat acor_dsb.dat acor_el-GR.dat acor_en-AU.dat acor_en-GB.dat acor_en-US.dat acor_en-ZA.dat acor_es.dat acor_fa-IR.dat acor_fi-FI.dat acor_fr.dat acor_ga-IE.dat acor_hr-HR.dat acor_hsb.dat acor_hu-HU.dat acor_is-IS.dat acor_it.dat acor_ja-JP.dat acor_ko-KR.dat acor_lb-LU.dat acor_lt-LT.dat acor_mn-MN.dat acor_nl-BE.dat acor_nl-NL.dat acor_pl-PL.dat acor_pt-BR.dat acor_pt-PT.dat acor_ro-RO.dat acor_ru-RU.dat acor_sk-SK.dat acor_sl-SI.dat acor_sr-CS.dat acor_sr-Latn-CS.dat acor_sr-Latn-ME.dat acor_sr-Latn-RS.dat acor_sr-ME.dat acor_sr-RS.dat acor_sv-SE.dat acor_tr-TR.dat acor_vi-VN.dat acor_zh-CN.dat acor_zh-TW.dat
this doesn't seems like an enhancement
"Bug" (Slowdown) still exists in 7.0 Beta 2
Interesting. Noticed the same thing, but for Interface languages :-)
@SBerg, It would be really nice if you could do launch perf analysis (on Windows, plz; Linux is pretty OK I think) with all bells and whistles installed someday at some time. My impression: it's checking Interface Languages/Extensions on every launch in a pretty consuming way. Removing extensions and launching LibreOffice is comparability slow (splash screen shows disabling.. followed by all the dictionary's in case of dictionary removal). But that's of course a n00b assessment.. Eventually including say: languagetool (https://languagetool.org) ; however not sure who to 'blame' for that) Some reviews still complaining about LibreOffice launching slowly (on Windows) and this surely doesn't help, IMHO. It's still 'a mystery' (rhetorical) how we end up with so many Linux LibreOffice developers; while the majority of the users using Windows. The love for Windows (perf) issues always a bit less compared to Linux :-(
To measure the impact of reading all the *.xcd files under share/registry/ (whose number grows with the number of installed language packs) on start-up of LibreOffice, I did the following: With a (non-debug) local build of recent LibreOffice master on Windows, including the patch > diff --git a/configmgr/source/components.cxx b/configmgr/source/components.cxx > index f7bd5ba34e3a..c64452f80a7e 100644 > --- a/configmgr/source/components.cxx > +++ b/configmgr/source/components.cxx > @@ -1,3 +1,4 @@ > +#include<iostream> > /* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ > /* > * This file is part of the LibreOffice project. > @@ -497,7 +498,7 @@ Components::Components( > if (type == "xcsxcu") { > sal_uInt32 nStartTime = osl_getGlobalTimer(); > parseXcsXcuLayer(layer, url); > - SAL_INFO("configmgr", "parseXcsXcuLayer() took " << (osl_getGlobalTimer() - nStartTime) << " ms"); > + std::cerr<<"\nparseXcsXcuLayer() took " << (osl_getGlobalTimer() - nStartTime) << " ms\n"; > layer += 2; //TODO: overflow > } else if (type == "bundledext") { > parseXcsXcuIniLayer(layer, url, false); > @@ -521,7 +522,7 @@ Components::Components( > } else if (type == "res") { > sal_uInt32 nStartTime = osl_getGlobalTimer(); > parseResLayer(layer, url); > - SAL_INFO("configmgr", "parseResLayer() took " << (osl_getGlobalTimer() - nStartTime) << " ms"); > + std::cerr<<"\nparseResLayer() took " << (osl_getGlobalTimer() - nStartTime) << " ms\n"; > ++layer; //TODO: overflow > #if ENABLE_DCONF > } else if (type == "dconf") { to print timing information about reading (the two different bunches of) those *.xcd files: * A --with-lang=ALL build prints > parseXcsXcuLayer() took 114 ms > > parseResLayer() took 2586 ms when running instdir/program/soffice.exe, and a crude stopwatch measurement from start to showing the startcenter window takes 4.50 sec. * A --with-lang=en-US build prints > parseXcsXcuLayer() took 72 ms > > parseResLayer() took 2 ms when running instdir/program/soffice.exe, and a crude stopwatch measurement from start to showing the startcenter window takes 1.55 sec. So this reading of all *.xcd files indeed accounts for a measurable part of the slowdown. (Maybe more so than on e.g. Linux, as accessing many individual files is purportedly slow on Windows.) But in the context of the original comment 0, I see no room at least for obvious, "low-hanging" improvement here, nor an indication that speeding up the many-LanguagePacks scenario would also benefit the single-LanguagePack scenario's start-up time.
Dear bugzilla2, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still exists in current master. Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: dc92a4d973086ce8a6a5f75ba0f4d4c9ca05537a CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: de-AT (de_AT); UI: de-DE Calc: CL threaded