Bug 279026 - REGRESSION(281488@main): [WPE][GTK] Process launching is slow
Summary: REGRESSION(281488@main): [WPE][GTK] Process launching is slow
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-02 10:20 PDT by Michael Catanzaro
Modified: 2024-09-10 08:29 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 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.
Comment 1 Michael Catanzaro 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.
Comment 2 Michael Catanzaro 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.)
Comment 3 Michael Catanzaro 2024-09-06 17:16:14 PDT
Pull request: https://github.com/WebKit/WebKit/pull/33270
Comment 4 EWS 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.