Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4f1ddc1d813f89f2a529c841dcdbb5b038d8d63a
https://github.com/WebKit/WebKit/commit/4f1ddc1d813f89f2a529c841dcdbb5b038d8d63a
Author: Dan Glastonbury <[email protected]>
Date: 2026-08-21 (Fri, 21 Aug 2026)
Changed paths:
M Source/WebKit/Platform/IPC/StreamClientConnection.h
M Source/WebKit/Platform/IPC/StreamClientConnectionBuffer.h
Log Message:
-----------
Avoid constructing a Timeout on the common stream IPC send path
https://bugs.webkit.org/show_bug.cgi?id=322259
rdar://185490398
Reviewed by Kimmo Kinnunen.
Timeout's constructor eagerly computes ApproximateTime::now() + delta, but
StreamClientConnection::send() only consults the deadline if tryAcquire() has to
block, which is rare since the ring buffer normally has room. The cost was paid
on every message, and showed up in MotionMark 1.3 Suits profiles where IPC
accounted for ~22% of samples.
Add StreamClientConnectionBuffer::acquireNoWait() for the non-blocking case and
try it first when the destination ID is unchanged, falling back to the existing
Timeout-based path otherwise. Skipping trySendDestinationIDIfNeeded() on that
fast path is equivalent to the early return it would have taken, since
m_currentDestinationID is only assigned after the SetStreamDestinationID message
has been released. Timeout keeps its by-value semantics, so the shared budget
across trySendDestinationIDIfNeeded() + tryAcquire() is unaffected.
* Source/WebKit/Platform/IPC/StreamClientConnection.h:
(IPC::StreamClientConnection::send):
* Source/WebKit/Platform/IPC/StreamClientConnectionBuffer.h:
(IPC::StreamClientConnectionBuffer::acquireNoWait):
Canonical link: https://commits.webkit.org/319636@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
