| Summary: | REGRESSION(281488@main): [WPE][GTK] Process launching is slow | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Michael Catanzaro <mcatanzaro> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=262794 | ||
|
Description
Michael Catanzaro
2024-09-02 10:20:55 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. 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.) Pull request: https://github.com/WebKit/WebKit/pull/33270 Committed 283414@main (cf8f5f540b30): <https://commits.webkit.org/283414@main> Reviewed commits have been landed. Closing PR #33270 and removing active labels. |