In the profile, launching a new content processes took one full second, with the time spent in `IPCBlobUtils::Serialize`, `PContentParent::SendInitBlobURLs` , and `IPC::ParamTraits::Read`. But even more importantly, it looks like whenever any content process is shutting down, all IPC to the parent process is blocked for 4 seconds! Those four seconds are spent in `Node::DestroyAllPortsWithPeer`. Nika, who would be the right person to look into this?
Bug 1981051 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In the profile, launching a new content processes took one full second, with the time spent in `IPCBlobUtils::Serialize`, `PContentParent::SendInitBlobURLs` , and `IPC::ParamTraits<mozilla::dom::BlobURLRegistrationData>::Read`. But even more importantly, it looks like whenever any content process is shutting down, all IPC to the parent process is blocked for 4 seconds! Those four seconds are spent in `Node::DestroyAllPortsWithPeer` on the `IPC I/O` thread. Nika, who would be the right person to look into this?
In [the profile](https://share.firefox.dev/4oo0Gyz), launching a new content processes took one full second, with the time spent in `IPCBlobUtils::Serialize`, `PContentParent::SendInitBlobURLs` , and `IPC::ParamTraits<mozilla::dom::BlobURLRegistrationData>::Read`. But even more importantly, it looks like whenever any content process is shutting down, all IPC to the parent process is blocked for 4 seconds! Those four seconds are spent in `Node::DestroyAllPortsWithPeer` on the `IPC I/O` thread. Nika, who would be the right person to look into this?