Steps to reproduce: 1. Launch Impress using ca-ES-valencia locale ( not happening using ca-ES ) 2. Click on the title/subtitle textbox 3. LibreOffice hangs for a few seconds Surprisingly, it's only happening with ca-ES-valencia locale Reproduced in Versió: 6.3.1.2 ID de la construcció: 1:6.3.1~rc2-0ubuntu0.18.04.1~lo1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: es-ES (ca_ES.UTF-8); Llengua de la IU: ca-ES-valencia Calc: threaded
Actually, it happens when the UI is in ca-ES-valencia, not when the locale is in ca-ES-valencia
Also reproducible in a local build using --with-lang=ca-valencia Versió: 6.4.0.0.alpha0+ ID de la construcció: 586de7ac433dca98edf4a5a3d13b5e393b9880ed CPU threads: 4; OS: Linux 4.15; UI render: per defecte; VCL: gtk3; Configuració local: en-US (ca_ES.UTF-8); UI-Language: ca-ES-valencia Calc: threaded
Hi Julien, Any chance you could get a perf chart here ?
Hi Eike, I'm wondering if this issue is related to 'BCP 47 language tag' work you did in the past ( e.g. https://cgit.freedesktop.org/libreoffice/core/commit/?id=c2bd06120b932bf3757f19bdf8c8d9ee8a31f557 )
(In reply to Xisco Faulí from comment #3) > Hi Julien, > Any chance you could get a perf chart here ? Ok but I hope I'll find the way to use "ca-ES-valencia" easily without rebuilding from scratch since it may require to add some language in autogen.input.
(In reply to Julien Nabet from comment #6) > (In reply to Xisco Faulí from comment #3) > > Hi Julien, > > Any chance you could get a perf chart here ? > > Ok but I hope I'll find the way to use "ca-ES-valencia" easily without > rebuilding from scratch since it may require to add some language in > autogen.input. I also rebuilt Libo with --with-lang=ca-valencia, and it took me 3 minutes...
Great if it works without rebuilding the whole sources!
Created attachment 154560 [details] perf flamegraph On pc Debian x86-64 with master sources updated today + enable-symbols + ca-valencia locale, I could reproduce this. I attached Flamegraph
(In reply to Julien Nabet from comment #9) > Created attachment 154560 [details] > perf flamegraph > > On pc Debian x86-64 with master sources updated today + enable-symbols + > ca-valencia locale, I could reproduce this. > I attached Flamegraph Moving to NEW based on this comment
@Noel, does the perf chart gives you any clue why LibreOffice is so slow only with this UI locale ?
I suspect something is going wrong with our locale caching and we are repeatedly reloading the locale.
Perhaps bibisect this, could be a consequence of caolan's locale work from some time ago
(In reply to Noel Grandin from comment #13) > Perhaps bibisect this, could be a consequence of caolan's locale work from > some time ago The problem with the bisect repositories is that they are only built with English UI @Caolán, any idea about this one ?
Possibly unotools/source/i18n/resmgr.cxx Translate::Create is the thing to look at here. We are caching on rLocale.getGlibcLocaleString() which I'm guessing is slow for this language variant case, in which case simply caching on the input rLocale or rLocale.getBcp47() might be the way to go
The massive amount of lt_tag_convert_to_locale() calls from LanguageTagImpl::getGlibcLocaleString() (called from SvxResId/SvxResLocale) and the time spent therein looks fishy. This wasn't a problem when string resources came from the old resource system as conversion to the Glibc string wasn't needed often, but now for .po files the conversion is needed for each resource string which it wasn't before. The Glibc string can be constructed much quicker for locales that do not involve a Script tag or @modifier in the Glibc representation and LanguageTagImpl::getGlibcLocaleString() isn't even called then, hence it affects only ca-ES-valencia (ca_ES@valencia) and a few others. We probably want to cache the Glibc string in class LanguageTagImpl. Taking.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/24c7c12224f1c1d66f335f6fe085595352137646 Resolves: tdf#127786 cache Glibc locale string in LanguageTagImpl It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/79775 for 6-3
Verified in in local build including https://git.libreoffice.org/core/commit/24c7c12224f1c1d66f335f6fe085595352137646. @Eike, thanks for fixing this issue!! Do you think it would be good to backport it to 6-2-8 as well?
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/99782b52c3cc25a32661c382ca98a32f6ec87003 Resolves: tdf#127786 cache Glibc locale string in LanguageTagImpl It will be available in 6.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Xisco Faulí from comment #19) > Do you think it would be good to backport it to 6-2-8 as well? Theoretically yes, but as always, 6.2.8 will be the last 6.2.x release, so if anything goes wrong.. it should not, but.. ;-)
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/commit/e7b8101cf7643d612393079d7f1cea07d8b1c774 Resolves: tdf#127786 cache Glibc locale string in LanguageTagImpl It will be available in 6.2.9. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-2-8": https://git.libreoffice.org/core/commit/5fec105e6de0005918e9f6f69aafe7ec51a9998f Resolves: tdf#127786 cache Glibc locale string in LanguageTagImpl It will be available in 6.2.8. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.