https://bugs.documentfoundation.org/show_bug.cgi?id=159375
Bayram Çiçek <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #14 from Bayram Çiçek <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
