Description: Opening Tools > Options takes too much time, and in recent versions, it has grown beyond the users' expectations. There is a general rule in some human interface guidelines that the response time of the UI should be less than 0.1 second, and then the user will think the action is almost instant. The response time between 0.1s and 1s is acceptable. But having response time more than 10 seconds risks the users abandoning the software, and this is not acceptable. Response Times: The 3 Important Limits https://www.nngroup.com/articles/response-times-3-important-limits/ With the latest changes in LibreOffice, 1 second response time limit is passed, and at least debug build also fails with the 10 seconds threshold. This is important, as LibreOffice users usually have to set many things in the Options dialog, and having that bad latency is destructive. I think the reason for such high latency can be the (actually nice and useful) feature that introduced search filed in the Options dialog: https://bugs.documentfoundation.org/show_bug.cgi?id=49895 Here I compare the time when clicking on Tools > Options and the appearance of the dialog after a cold start (run LO, click on Tools > Options immediately): OpenOffice.org 3.2.1 OOO320m18 (Build: 9502) Almost instant Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Seems to be less than 1 second Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Seems to be around 2 seconds. These rough measurements are office TDF release builds installed on my computer, which is a relatively fast one. Looking into the some HIG recommendations like the above link, I think everything beyond 1 second is problematic. Therefore, it is needed to measure the response time, and make sure the response time is acceptable. Having a mouse pointer with busy icon is good, but it is not enough.
Hossein, I see 1 second in Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded And also in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c479944eb4f9f5a22c7b248185f22c86ea85d12a CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded How can be run a code to analyze what is generating that delay you have noticed?
Also present on macOS Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ba8f4bff6015013013df652efbfaf4d9ae10c881 CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded I have observed the same on Windows.
The reason why opening "Tools > Options" takes a bit more time than expected is that; in order to make searching ready, we need to get all strings from the UI and this requires instantiating all dialogs (which takes a lot time) under the "Tools > Options". Here we initialize first 25 dialogs while opening Options dialog: https://gerrit.libreoffice.org/c/core/+/152519/36/cui/source/options/treeopt.cxx#1202 .Then, other uninitialized dialogs are initialized at the time of search. The idea was that initialize half of the dialogs at startup of "Options dialog", then initialize other half at the time of searching; so that searching can be fast. The more dialog initialized before searching the more searching be fast. Anyway, my suggestion is that: don't initialize the dialogs at the opening of "Options" but initialize all dialogs at the time of searching. In that way, there will be no latency of opening "Tools > Options" but disadvantage will be that searching will take a bit more time. What do you think? I am open to any suggestions on this. Thanks!
I notice the difference between first and second time it is open. Significant enough to notice the delay compared to other dialogs. Indeed, it started with a4633dadb4233ad5587bd238449671d610540c81, the fix for bug 49895 (build [418e06688c9c388d95dd968db114337a6aad9aa5] in linux-64-24.2 bibisect repo). (In reply to Bayram Çiçek from comment #3) > Anyway, my suggestion is that: don't initialize the dialogs at the opening > of "Options" but initialize all dialogs at the time of searching. In that > way, there will be no latency of opening "Tools > Options" but disadvantage > will be that searching will take a bit more time. I assume the delay would be only for the first search, and if the indexing happens as soon as the field is clicked, it might be barely noticeable as it takes some time for the user to type their query. I'd go with that! :)
*** Bug 160679 has been marked as a duplicate of this bug. ***
(In reply to Bayram Çiçek from comment #3) > The idea was that initialize half of the dialogs at startup of "Options > dialog", then initialize other half at the time of searching; so that > searching can be fast. The more dialog initialized before searching the more > searching be fast. > > Anyway, my suggestion is that: don't initialize the dialogs at the opening > of "Options" but initialize all dialogs at the time of searching. In that > way, there will be no latency of opening "Tools > Options" but disadvantage > will be that searching will take a bit more time. > > What do you think? I am open to any suggestions on this. I think another approach can be creating a search database at compile time. In this way, it will be ready at execution time, without any delays. You may initialize the dialogs, dump strings and write them to some files, and then re-use that at runtime. You may need to do this for each and every language, as the translations are important here.
(In reply to Hossein from comment #6) > I think another approach can be creating a search database at compile time. What about user-installed extensions that add a panel to the Options dialog, like some language extensions?
(In reply to Stéphane Guillou (stragu) from comment #7) > (In reply to Hossein from comment #6) > > I think another approach can be creating a search database at compile time. > What about user-installed extensions that add a panel to the Options dialog, > like some language extensions? How can that help in performance? Even in that case, there should be some solution to speed up the indexing phase.
(In reply to Hossein from comment #6) > (In reply to Bayram Çiçek from comment #3) > > The idea was that initialize half of the dialogs at startup of "Options > > dialog", then initialize other half at the time of searching; so that > > searching can be fast. The more dialog initialized before searching the more > > searching be fast. > > > > Anyway, my suggestion is that: don't initialize the dialogs at the opening > > of "Options" but initialize all dialogs at the time of searching. In that > > way, there will be no latency of opening "Tools > Options" but disadvantage > > will be that searching will take a bit more time. > > > > What do you think? I am open to any suggestions on this. > I think another approach can be creating a search database at compile time. > In this way, it will be ready at execution time, without any delays. You may > initialize the dialogs, dump strings and write them to some files, and then > re-use that at runtime. You may need to do this for each and every language, > as the translations are important here. We tried this approach but we saw that this approach makes the implementation more complex - especially when it comes to different languages (translations etc...)
(In reply to Hossein from comment #8) > (In reply to Stéphane Guillou (stragu) from comment #7) > > (In reply to Hossein from comment #6) > > > I think another approach can be creating a search database at compile time. > > What about user-installed extensions that add a panel to the Options dialog, > > like some language extensions? > How can that help in performance? Even in that case, there should be some > solution to speed up the indexing phase. I think you misunderstood me. I mean: compile-time indexing does not include the extra panels that might be added to the Options dialog when the user installs an extension after installation, and therefore would not be included in the search results.
(In reply to Bayram Çiçek from comment #9) > > I think another approach can be creating a search database at compile time. > > In this way, it will be ready at execution time, without any delays. You may > > initialize the dialogs, dump strings and write them to some files, and then > > re-use that at runtime. You may need to do this for each and every language, > > as the translations are important here. > We tried this approach but we saw that this approach makes the > implementation more complex - especially when it comes to different > languages (translations etc...) Could you please describe how did you try this approach? And what were the issues that made it so complex? (In reply to Stéphane Guillou (stragu) from comment #10) > I think you misunderstood me. I mean: compile-time indexing does not include > the extra panels that might be added to the Options dialog when the user > installs an extension after installation, and therefore would not be > included in the search results. Aha, OK! Now I understand what you mean. We can have a compromise for that: index pre-built options at compile time, and then add indexes for the remaining at run-time.
(In reply to Hossein from comment #11) > (In reply to Bayram Çiçek from comment #9) > > > I think another approach can be creating a search database at compile time. > > > In this way, it will be ready at execution time, without any delays. You may > > > initialize the dialogs, dump strings and write them to some files, and then > > > re-use that at runtime. You may need to do this for each and every language, > > > as the translations are important here. > > We tried this approach but we saw that this approach makes the > > implementation more complex - especially when it comes to different > > languages (translations etc...) > Could you please describe how did you try this approach? The latest work done about this approach was in patchset 15 (and in previous ones): https://gerrit.libreoffice.org/c/core/+/152519/15 > And what were the issues that made it so complex? As far as I remember, there were some improvements needed in some makefiles (e.g. solenv/gbuild/UIConfig.mk), also further work needed to be done such as fetching the generated data at run-time, localization etc. I had a limited time to implement this idea and we couldn't estimate the time needed for this build-time extraction approach. I agree that this build-time approach is the best way to implement the idea - without initializing all dialogs at the start of Options dialog.
Is it possible to start gathering the strings in a dedicated thread (immediately at dialog start, but without blocking it)? And if a user starts searching, block until that thread finished. I bet, that in 90%+, users won't be that fast to notice the delay.
(In reply to kolAflash from comment https://bugs.documentfoundation.org/show_bug.cgi?id=49895#c30) (Moving & replying the comment here) > @Bayram Çiçek > > It seems your patch slowed down loading the options dialog noticeably. > https://git.libreoffice.org/core/+/ > a4633dadb4233ad5587bd238449671d610540c81%5E%21 > With LibreOffice-24.2 it's about 10 times slower than with LibreOffice-7.6. > (before LibreOffice-7.1 the options loaded slow because of bug 146852) > > It's not a disaster. But on slower computers you really have to wait > multiple seconds since LibreOffice-24.2. I guess on older computers this can > exceed 10 seconds while being 1 second in LibreOffice-7.6. Yes, unfortunately we have to initialize all dialogs to get their UI string values to include them in searching. Otherwise, they are not accessible... > Reproduction: > Tools -> Options > Measure the time until the Options window is opened. > NOTE: > It's just the first time the Options are being opened after starting > LibreOffice. For repeating the test you have to restart LibreOffice. That's true. We save the UI strings -at the time of opening Tools>Options- into a list and they live until the LibreOffice application closes. In that way, we don't need to initialize the all dialogs again and again; we just read the strings from the list, if the Options dialog is opened again (without closing the LO application) > I've tested exactly your commit using this Git repo with binaries. > https://bibisect.libreoffice.org/linux-64-24.2.git > See also: https://wiki.documentfoundation.org/QA/Bibisect > The binary commit 418e06688 in that repo corresponds to the a4633dadb commit > in https://git.libreoffice.org/core/ > 418e06688^ is fast and 418e06688 is slow. > > On my Ryzen-5650U @ 2.3 GHz (4.2 GHz boost) notebook CPU it's just half a > second. But if I slow down the CPU to the minimum of 1.6 GHz and disable the > boost it's already over a second. While LibreOffice-7.6 stays nicely below > half a second. > /sys/devices/system/cpu/cpufreq/boost > /sys/devices/system/cpu/cpu*/cpufreq/{boost,scaling_max_freq} > > I've got a low power Celeron-J4105 CPU system on which it's below 1 second > with 418e06688^ and over 4 seconds with 418e06688 > If I throttle the CPU to 800 MHz 418e06688^ stays below 1 second while > 418e06688 needs over 8 seconds. > And I guess on a Raspberry Pi 4 or 5 used as a desktop computer it's even > slower. > > > Even on high speed CPUs you can see it clearly if you "cpulimit" to limit > the computing power available to the process. On my Ryzen-5650U limited to > 1.6 GHz with boost disabled this is over 8 seconds with 418e06688 > https://packages.debian.org/bookworm/cpulimit > # first shell (limit process to CPU core 0) > soffice > # second shell > sudo cpulimit -fv -l2 -e soffice.bin > > Operating system on all machines: Debian-12 > Same results for Upstream-LibreOffice-7.6, Debian-12-LibreOffice-7.4 and > LibreOffice 418e06688^ > > > > The problem seems to boil down to this eager preloading. > initializeFirstNDialog(25); > https://git.libreoffice.org/core/+/3b50600e8f817409f5a21249871d9f82728e4987/ > cui/source/options/treeopt.cxx#1201 I was expecting that slowness on low-power systems. There are almost 70 dialogs need to be initialized. If 25 of them are so slow, then I can't imagine the slowness of initializing the 70 of them during search... > Although if I reduce the number from 25 to 1, I get a strange effect that > didn't exist in 418e06688^. Some sections in the options dialog like > LibreOffice->View get loaded really slow when clicking them. But not all > sections are affected. I need to check that strange effect. I remember we had issues like that in some OSes (especially on Windows) > > So I'd consider removing this preloading (equivalent to setting the value to > 1) less bad than the situation since LibreOffice-24.2. Because then you've > only have to wait when clicking one of the slow sections or when using the > search function (initializing the search takes some time with a value of 1). > Ideally a user would only have to wait when using the new search feature. > But I haven't figured out yet if or how that's possible. I asked myself & thought the same while working on Options dialog. However, as I mentioned earlier, you can't access anything without open/initialize the dialog(s). This makes the implementation very difficult than it should be. (regarding the topic, see also: https://bayramcicek.github.io/libreoffice-dev/2023/06/18/week-03-gsoc-report.html) > (very ideally a user never has to wait ;-) but I guess the new search > feature just needs time to initialize) There is actually another way to extract strings: create a search database at compile time, use it at run-time. You can read the older comments about this. Let me try to work on that to see what we can do about it... Thank you.
(In reply to Bayram Çiçek from comment #14) > (In reply to kolAflash from comment > https://bugs.documentfoundation.org/show_bug.cgi?id=49895#c30) (Moving & > replying the comment here) > > > @Bayram Çiçek > > > > It seems your patch slowed down loading the options dialog noticeably. > > [...] > [...] > > Ideally a user would only have to wait when using the new search feature. > > But I haven't figured out yet if or how that's possible. > > I asked myself & thought the same while working on Options dialog. However, > as I mentioned earlier, you can't access anything without open/initialize > the dialog(s). This makes the implementation very difficult than it should > be. (regarding the topic, see also: > https://bayramcicek.github.io/libreoffice-dev/2023/06/18/week-03-gsoc-report. > html) > > > (very ideally a user never has to wait ;-) but I guess the new search > > feature just needs time to initialize) > > There is actually another way to extract strings: create a search database > at compile time, use it at run-time. You can read the older comments about > this. > > Let me try to work on that to see what we can do about it... > > Thank you. Thank you too for the detailed answer :-) Please tell me if I can help out. It would be nice to have this resolved soon. No waiting at all would definitely be ideal. But if that's too time consuming to implement in the next couple of month, I'd vote for simply removing the preloading as you mentioned in comment 3. When using the search feature I think it doesn't matter at which point you've to wait (when loading the options or when starting the search). And if you don't use the search you're done much faster without the preloading.
(In reply to kolAflash from comment #15) > When using the search feature I think it doesn't matter at which point > you've to wait (when loading the options or when starting the search). As long it wont feel broken. My first idea is to run the initialization in the background aka threaded. If that wont help and if you continue with the no-init-but-wait-on-first-search idea, please indicate the loading process for example with a throbber in the input field.
(In reply to kolAflash from comment #15) > Please tell me if I can help out. It would be nice to have this resolved > soon. I've just removed the initialization on Options startup. Could you please test&feedback: https://gerrit.libreoffice.org/c/core/+/167023
(In reply to Mike Kaganski from comment #13) > Is it possible to start gathering the strings in a dedicated thread > (immediately at dialog start, but without blocking it)? I tried this but I couldn't find a way to initialize them as "headless". It always updates the UI (blocking), so using a thread didn't work. But this was a ~year ago. I need to try/check it again.
(In reply to Heiko Tietze from comment #16) > (In reply to kolAflash from comment #15) > > When using the search feature I think it doesn't matter at which point > > you've to wait (when loading the options or when starting the search). > As long it wont feel broken. > > My first idea is to run the initialization in the background aka threaded. I'll try that (not now but after I have some time). > If that wont help and if you continue with the > no-init-but-wait-on-first-search idea, please indicate the loading process > for example with a throbber in the input field. If using threads won't work, I will try to add an indicator for the loading process.
Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd3953f705cc19aad4b0fcec7fd2961246b659e3 tdf#159375: remove initialization on Tools>Options It will be available in 24.8.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.
@Bayram Could you cherry-pick dd3953f70 for libreoffice-24-2 ? I've already tested that and it works like a charm :-) Thanks! https://git.libreoffice.org/core/+/dd3953f705cc19aad4b0fcec7fd2961246b659e3%5E%21 https://git.libreoffice.org/core/+/refs/heads/libreoffice-24-2
(In reply to kolAflash from comment #21) > @Bayram > Could you cherry-pick dd3953f70 for libreoffice-24-2 ? Has just become obsolete. My colleague Stephan already did that. https://gerrit.libreoffice.org/c/core/+/167222
Bayram Çiçek committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/0aef29521b824e61b81bb6be1079b8ddd77e39a9 tdf#159375: remove initialization on Tools>Options It will be available in 24.2.4. 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.
Feel free to close as fixed.
Thanks Bayram, feels nice and responsive in: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1f15d097cace14ca6e44e7652f460aa3fa7bd150 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/734914261347d51dfd4f1140b037c52c86060277 tdf#159375: turn cursor into a wait cursor while search It will be available in 24.8.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.