phase1geo
Startup is very slow
Starting the application is very slow. Any ideas why and for improving startup times?
Here's the relevant lines from the attached strace minder-strace.log showing that it blocks for 25 seconds when loading:
1607487463.293313 futex(0x5618c2780e20, FUTEX_WAKE_PRIVATE, 1) = 1 1607487463.293470 futex(0x5618c27780c8, FUTEX_WAKE_PRIVATE, 1) = 1 1607487463.293528 eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11 1607487463.293579 write(11, "\1\0\0\0\0\0\0\0", 8) = 8 1607487463.293710 write(6, "\1\0\0\0\0\0\0\0", 8) = 8 1607487463.293774 futex(0x5618c27780c8, FUTEX_WAKE_PRIVATE, 1) = 1 1607487463.293828 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}]) 1607487463.293891 read(11, "\1\0\0\0\0\0\0\0", 16) = 8 1607487463.293945 poll([{fd=11, events=POLLIN}], 1, 25000) = 0 (Timeout) 1607487488.301952 write(11, "\1\0\0\0\0\0\0\0", 8) = 8 1607487488.302131 futex(0x5618c27ecea0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 1607487488.302259 close(11) = 0 1607487488.302584 write(6, "\1\0\0\0\0\0\0\0", 8) = 8 1607487488.302831 futex(0x5618c27780c8, FUTEX_WAKE_PRIVATE, 1) = 1 1607487488.303106 futex(0x5618c27780c8, FUTEX_WAKE_PRIVATE, 1) = 1
What version of Minder are you using? Additionally, what is the package manager that was used to install it?
Unfortunately, the logfile that you have provided doesn't provide much insight for me into what the application is attempting to do. Did you have several files opened within Minder when it was previously closed? Where there lots of images within those mind maps?
I know that some users of the Flatpak have expressed slowness of the application.
This is on Ubuntu 20.04. Same behavior with the apt install minder version as well as the latest source version.
It might not be a minder-specific issue, but something to do with GTK, as I'm not using the Gnome desktop. If it is a GTK issue, I would like to take this upstream - and the same time explore whether this can be circumvented locally...
I guess a good start from my side would be to grep the Gnome universe for "poll" and "25000". Would like to track it here if you don't mind...
Okay, so this is the Gnome dbus timeout. So really something that needs to be addressed upstream. Why it's so long is something I can take up with Gnome.
As for a workaround... easy to argue that this is not the place. Yet, I can think of two ways.
- See if there's a mechanism to find the relevant dbus environment - and read that, and/or launch it, before initializing Gtk.
- See if its possible to wait in the background. I guess if there's some state that needs to come from the bus, such as something about the theme, or something else then it would need to be a dynamic update mechanism...
- Shorten the timeout
- Reduce dependency on it
A workaround is not mandated here... but if there was one, then it would ensure that this application is favored above other GTK apps that have the delay, so it is a potential way to get a wider community.
Looks like this is the smoking gun behind possibly most delay or timeout complaints pertaining to free desktops, on the internet: https://cgit.freedesktop.org/dbus/dbus/tree/bus/config-parser.c#n505