Created attachment 148527 [details] Valgrind of a session running over NX technology. In testing version 6.2, it was noticed there was a big performance issue at cold start. 6.1 is opening in about 2 seconds, and 6.2 takes about 5-6 seconds before it's fully rendered. If the VCL is changed from default GTK3 back to GTK2, it immediately gets much faster. We have many other GTK3 apps running and are not seeing any performance issues this badly. LibreOffice is being run from large multi-user servers using the NX Xserver. Your larger enterprise customers may have similar issues as they move this version live. This technique is similar to using VNC to run an Xserver, and it's possible the performance issue would be seen using this software as well. In the past, when these types of things happen, the local video card of the computer is compensating for the issue so it's not noticed. When LO opens, the initial canvas appears and then slowly the icons and pulldown menus appear when in GTK 3. I did a valgrind and will attach. Not sure what else I can do to help.
Noted, this is on Linux.
Dave, how familiar are you with bibisecting? [1] This could probably be bibisected with repo bibisect-linux-64-6.2 [2]. [1] https://wiki.documentfoundation.org/QA/Bibisect [2] https://wiki.documentfoundation.org/QA/Bibisect/Linux
@Aron: I have done a bibisect before. I'm not sure it's appropriate here because I don't think the GTK3 VCL ever worked correctly. In versions <= 6.1, it defaults to GTK2. With 6.2, it's defaulting to GTK3 as I understand it. I think there is a low level performance issue here. If we can solve my issue, we should also get a nice boost even for those users with local video cards.
Indeed, I didn't notice there was a switch between 6.1 and 6.2.
Any update with 6.2.4? Do you still see this perf issue in gtk3 compared to gtk2? Also, Valgrind is used to find memory management pb. I supposed you'd need callgrind or Flamegraph?
Now that GTK2 is removed from LibreOffice, I have been looking at this again. 6.3 and 6.4 are horribly slow when run from servers that do not have a local video card. Document loading is very slow as well as widget rendering. A document that opens in 2 seconds in GTK2 takes about 30 seconds with GTK3 enabled. When I change VCL to "gen", it immediately gets lightning fast and works great. I ran perf on it and am uploading the logs. Please let me know if this is providing anything useful.
Created attachment 156524 [details] Perf data from slow session.
Created attachment 156527 [details] Flamegraph on perf.data I tried to generate the Flamegraph but it's not very explicit
The best thing would be to build LO (see https://wiki.documentfoundation.org/Development/BuildingOnLinux) with enable-symbols then retrieve a complete Flamegraph by following https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_Flamegraph. But I'd understand you'd refuse since it takes quite some time. Perhaps there are other ways to fix this but don't know them.
Just for information, doc about Flamegraph moved, see https://wiki.documentfoundation.org/Development/How_to_debug#Performance_debugging_.28perf.29
Thanks guys for your comments, I had some time to work on this today. I tried to compile from source, and found that GCC is too old on our server. I have the instructions to install GCC 7 and will do that on our clone next week. But I did find something VERY interesting (by accident). In my testing, I was starting LO and then using the start center to open documents and they continue to load horribly slow. However, if I send the file directly to LO such as ./soffice <path_to_file> The same files open almost as quickly as they do in GTK2 and LO 6.3. So for sure, whatever is broken is in the start center. In summary: ./soffice <path_to_file> is pretty fast ./soffice, start center, then file > open the file is slow ./soffice, start center, then use recent documents is slow ./soffice, start center, then click on recent document thumbnail is slow.
What about clearing recent files and test again? Indeed, I wonder if LO doesn't test path of each recent files and if they're on a cloud, it can take some time.
Dear Dave Richards, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug