RESOLVED FIXED Bug 279026
REGRESSION(281488@main): [WPE][GTK] Process launching is slow 
https://bugs.webkit.org/show_bug.cgi?id=279026
Summary REGRESSION(281488@main): [WPE][GTK] Process launching is slow
Michael Catanzaro
Reported 2024-09-02 10:20:55 PDT
When running under flatpak, processes launching is visibly slow. When launching Epiphany, I can watch as it opens one tab at a time. I'm not certain, but my guess is this regressed in bug #262794. Unfortunately that is difficult to confirm since developing under flatpak is time-consuming and awkward. The easiest way to test will be to patch the GNOME runtime. I will add a patch to use the pid socket only when not running under flatpak, and also disable the web process cache so as not to reintroduce bug #262794. It's not the end of the world if web process cache is disabled.
Attachments
Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 2024-09-06 12:21:08 PDT
At great difficulty, I built a custom flatpak with some extra debug code to time how long we spend in IPC::readPIDFromPeer (in ConnectionUnix.cpp). With 14 tabs, it looks like this: Read pid from peer in 33 milliseconds Read pid from peer in 152 milliseconds (epiphany:2): Gtk-WARNING **: 14:15:57.155: Unable to retrieve the Flatpak portal version: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown Read pid from peer in 152 milliseconds Read pid from peer in 143 milliseconds Read pid from peer in 149 milliseconds Read pid from peer in 148 milliseconds Read pid from peer in 143 milliseconds Read pid from peer in 141 milliseconds Read pid from peer in 136 milliseconds Read pid from peer in 143 milliseconds Read pid from peer in 140 milliseconds Read pid from peer in 143 milliseconds Read pid from peer in 142 milliseconds Read pid from peer in 149 milliseconds Read pid from peer in 148 milliseconds I think the first process is quicker to spawn because it's the unsandboxed network process rather than the sandboxed web process. I repeated the test in my normal development environment, without flatpak: Read pid from peer in 21 milliseconds Read pid from peer in 40 milliseconds Read pid from peer in 41 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 42 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 42 milliseconds Read pid from peer in 43 milliseconds Read pid from peer in 42 milliseconds Read pid from peer in 41 milliseconds Read pid from peer in 41 milliseconds So flatpak makes things much worse, but I'd say performance is unacceptable in both cases.
Michael Catanzaro
Comment 2 2024-09-06 12:24:57 PDT
Sending the pid is instantaneous, though. I think the regression here is that the UI process now blocks for the amount of time that it takes to launch a subprocess. (And that's especially slow when using flatpak-spawn.)
Michael Catanzaro
Comment 3 2024-09-06 17:16:14 PDT
Pull request: https://github.com/WebKit/WebKit/pull/33270
EWS
Comment 4 2024-09-10 08:29:35 PDT
Committed 283414@main (cf8f5f540b30): <https://commits.webkit.org/283414@main> Reviewed commits have been landed. Closing PR #33270 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.