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? 
This could probably be bibisected with repo bibisect-linux-64-6.2 .
@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
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.