[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Bayram Çiçek changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |bayram.ci...@collabora.com |desktop.org | -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #20 from Commit Notification --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Commit Notification changed: What|Removed |Added Whiteboard||target:24.8.0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #19 from Bayram Çiçek --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #18 from Bayram Çiçek --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #17 from Bayram Çiçek --- (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: https://gerrit.libreoffice.org/c/core/+/167023 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #16 from Heiko Tietze --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #15 from kolAflash --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375
Bayram Çiçek changed:
What|Removed |Added
CC||kolafl...@kolahilft.de
--- Comment #14 from Bayram Çiçek ---
(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
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #13 from Mike Kaganski --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Bayram Çiçek changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=49 ||895 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #12 from Bayram Çiçek --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #11 from Hossein --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #10 from Stéphane Guillou (stragu) --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #9 from Bayram Çiçek --- (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...) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #8 from Hossein --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #7 from Stéphane Guillou (stragu) --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #6 from Hossein --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Stéphane Guillou (stragu) changed: What|Removed |Added CC||balls...@hotmail.com --- Comment #5 from Stéphane Guillou (stragu) --- *** Bug 160679 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Stéphane Guillou (stragu) changed: What|Removed |Added Version|24.2.0.1 rc |24.2.0.0 alpha0+ Keywords|bibisectRequest |bibisected, bisected CC||stephane.guillou@libreoffic ||e.org --- Comment #4 from Stéphane Guillou (stragu) --- 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! :) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Aron Budea changed: What|Removed |Added CC||aron.bu...@gmail.com Blocks||102187 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=102187 [Bug 102187] [META] Options dialog bugs and enhancements -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Telesto changed: What|Removed |Added Keywords||perf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 --- Comment #3 from Bayram Çiçek --- 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! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Telesto changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||bibisectRequest --- Comment #2 from Telesto --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 BogdanB changed: What|Removed |Added CC||buzea.bog...@libreoffice.or ||g --- Comment #1 from BogdanB --- 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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 159375] Opening Tools > Options dialog takes too long
https://bugs.documentfoundation.org/show_bug.cgi?id=159375 Hossein changed: What|Removed |Added Blocks||136524 CC||bayram.ci...@collabora.com Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=136524 [Bug 136524] [META] Performance/hang/lag/high CPU issues -- You are receiving this mail because: You are the assignee for the bug.
