Bug 123173 - Slow Start with many LanguagePacks/Dictionaries installed
Summary: Slow Start with many LanguagePacks/Dictionaries installed
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-05 10:18 UTC by bugzilla2
Modified: 2020-09-02 07:25 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla2 2019-02-05 10:18:06 UTC
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:
Comment 1 Xisco Faulí 2019-03-21 15:42:06 UTC
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
Comment 2 bugzilla2 2019-04-15 09:02:24 UTC
Hello Xisco,
Sorry for the late reply...
Just tested 6.2.3.2 and the performance issue still exists.
Comment 3 Xisco Faulí 2019-04-17 14:48:44 UTC
Could you please paste the info from Help - about LibreOffice ?
Comment 4 bugzilla2 2019-04-17 15:05:59 UTC
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
Comment 5 QA Administrators 2019-05-08 21:47:09 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2019-06-27 16:49:00 UTC
Could you please be more precise and inditate how many dictionaries you have installed at the same time and which ones ?
Comment 7 bugzilla2 2019-06-27 17:30:01 UTC
(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
Comment 8 QA Administrators 2019-06-28 03:00:50 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2019-09-03 08:04:19 UTC
this doesn't seems like an enhancement
Comment 10 bugzilla2 2020-06-27 10:32:07 UTC
"Bug" (Slowdown) still exists in 7.0 Beta 2
Comment 11 Telesto 2020-08-30 18:30:37 UTC
Interesting. Noticed the same thing, but for Interface languages :-)
Comment 12 Telesto 2020-08-30 18:53:26 UTC
@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 :-(
Comment 13 Stephan Bergmann 2020-09-02 07:25:15 UTC
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.