Repository navigation
perf(common): stop serializing every SDK request behind a 100ms poll - #14687
Merged
Merged
Conversation
hedgehogLib's waitUntil polled on a 100ms interval without checking the condition first, so hedgehog.waitUntilReady() cost a full tick even once the wallet was restored. The SDK's request-signature middleware calls it for every request inside a mutex, which spaced all API requests ~100ms apart in issue order and pushed page data (and the artwork requested after it) behind the shell's account/notification/comms calls. Resolve immediately when the condition already holds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Every SDK request on web goes through
addRequestSignatureMiddleware, which (inside a mutex) callsaudiusWalletClient.getAddresses()→getAccount()→hedgehog.waitUntilReady(). The common Hedgehog port'swaitUntilpolls withsetInterval(…, 100)and never checks the condition before the first tick, so an already-ready wait still costs a full 100 ms. Combined with the mutex, every API request starts ~100 ms after the previous one was issued, in issue order, even when the wallet has been ready since boot.On page load that queue is 8–12 requests logged out and 20+ logged in (account, notifications, comms, chats…), so page data such as Explore's shelves or the track page's lineup starts 1–2 s later than it could, and artwork, which is requested right after the data lands, inherits that delay. This is the dominant client-side contributor to "artwork still skeleton" on the pages reviewed for the design refresh. The same
waitUntilexisted in@audius/hedgehogbefore #14662, so this is not a regression from the viem port.What
waitUntilnow returns a resolved promise when the condition already holds; the 100 ms poll is only used while the wallet is still being restored. Two unit tests cover both paths. Mobile uses the same helper and gets the same benefit.Measurements
Headless Chrome (Playwright, 1440x900, logged out, cold cache, dev server with prod data, median of 3 runs, ms from navigation start). The built-in browser pane was not usable for this: when the pane is hidden the page gets no frames, idle callbacks only fire at their timeout, and lazy loading cannot trigger, which produced 10 s "stalls" that do not exist in a visible tab.
Logged out, only Explore has page data deep enough in the queue (requests 8–10) to show the win: its shelf data starts 0.9 s earlier and its artwork paints 1.0–1.7 s earlier. Trending, track and profile issue their page data first, so they are unchanged within dev-server noise (the track page's remaining 83 ms gap is its own dependent chain: stems, comments and remixes are issued after the track response). The track page's "after" runs also had a slower DOMContentLoaded (1.0–2.0 s vs 0.9 s) from Vite transforms, which shifts every column; relative to DOMContentLoaded they match.
Logged in, every page benefits: the ~20 account, notification and comms requests the shell issues at boot were ahead of page data in the same queue (in the pane, logged in, Trending's data request started 0.4 s after the first request and Explore's shelf data had not started 5 s in).
Request start gap = median spacing between consecutive API request starts (the serialization signature). "First art painted" = first
<img>from a content node withcomplete && naturalWidth > 0.Artwork requests themselves were never the problem: on all four pages the first content-node image request starts 30–200 ms after the data response, sizes are correct for the slot (150x150 tiles, 480x480 Explore cards, 1000x1000 hero only), and Explore's unloaded images are offscreen carousel tiles with
loading="lazy".🤖 Generated with Claude Code