Bug 122884 - Performance: GTK3 VCL Slow Using NX Xserver
Summary: Performance: GTK3 VCL Slow Using NX Xserver
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: perf
Depends on:
Blocks: GTK3 Network
  Show dependency treegraph
Reported: 2019-01-22 18:24 UTC by Dave Richards
Modified: 2019-12-13 21:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Valgrind of a session running over NX technology. (15.42 KB, application/x-bzip)
2019-01-22 18:24 UTC, Dave Richards
Perf data from slow session. (2.83 MB, application/x-bzip)
2019-12-12 19:54 UTC, Dave Richards
Flamegraph on perf.data (65.68 KB, application/x-bzip)
2019-12-12 20:26 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Richards 2019-01-22 18:24:53 UTC
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.
Comment 1 Dave Richards 2019-01-22 18:27:26 UTC
Noted, this is on Linux.
Comment 2 Aron Budea 2019-01-22 22:06:44 UTC
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
Comment 3 Dave Richards 2019-01-23 14:52:01 UTC
@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.
Comment 4 Aron Budea 2019-01-23 14:58:43 UTC
Indeed, I didn't notice there was a switch between 6.1 and 6.2.
Comment 5 Julien Nabet 2019-07-02 19:43:29 UTC
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?
Comment 6 Dave Richards 2019-12-12 19:52:51 UTC
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.
Comment 7 Dave Richards 2019-12-12 19:54:19 UTC
Created attachment 156524 [details]
Perf data from slow session.
Comment 8 Julien Nabet 2019-12-12 20:26:20 UTC
Created attachment 156527 [details]
Flamegraph on perf.data

I tried to generate the Flamegraph but it's not very explicit
Comment 9 Julien Nabet 2019-12-12 20:55:45 UTC
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.
Comment 10 Julien Nabet 2019-12-13 11:13:38 UTC
Just for information, doc about Flamegraph moved, see https://wiki.documentfoundation.org/Development/How_to_debug#Performance_debugging_.28perf.29
Comment 11 Dave Richards 2019-12-13 20:44:07 UTC
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.
Comment 12 Julien Nabet 2019-12-13 21:57:34 UTC
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.