Perf tracker: Solid primitives vs the hand-rolled `@yak/solid` runtime

[ryansolid]

DigitecGalaxus/next-yak#644 rewrote the @yak/solid styled() runtime and made it 12× faster on SSR and ~2× on hydrate/mount over its own base. Reading the PR against our code, almost every piece of the rewrite is a reimplementation of a Solid primitive that was too slow or too generic to use directly:

yak hand-rolls	instead of	because
serializeElement	ssrElement	needs a finished props object; walks getter-backed merged props again; emits style=""/class="" (#3382)
copyProps / proxyProps	merge / omit	proxy layers when any source is $PROXY; omit has no predicate/prefix form; plain path leaks $SOURCES (#3384)
createElementRenderer (template + getNextElement + spread + insert)	Dynamic / dynamic()	per-instance memo for a constant tag; no static class in the template; no runHydrationEvents; tag-only namespace (#3386)
shared withTheme proxy	merge(props, { theme })	one merge object per instance is measurable
once() on the server	createMemo	server memos are real nodes held until the deferred dispose (#3385)

This issue tracks closing those gaps so a library can call Solid and get the same numbers. Baseline harness: ryansolid/yak-bench — the 14 css-in-js-bench workloads, @yak/solid at the PR's base and head, both on 2.0.0-rc.8, with next-yak/React as the reference lane. Acceptance for every item below: a variant of the yak runtime using our primitive lands within noise of the hand-rolled one in that harness.

Where the remaining time goes

Solid 2.0.0-rc.8, @yak/solid at PR head. Full tables: SSR · Chromium.

Static styled intrinsics are fast (SSR 25× React, hydrate/mount 2–3.5× React). The cases still behind React are the ones that go through our generic paths — styled(Component) with {...rest} spreads, dynamic $props, imported primitives:

case	SSR PR/React	hydrate PR/React	mount PR/React
tabs (styled(Component) + spread)	1.10×	0.45×	0.63×
multifile-composition	1.05×	0.46×	0.64×
product-grid (400 tiles × 11 el)	4.15×	0.46×	0.81×
realistic-button	6.10×	0.72×	1.02×
dyn-fair (CSS var per element)	10.06×	0.81×	1.04×
btn-variant vs compose-1 (dynamic vs static props, same element)	2.7M vs 10M inst/s	30.4 vs 15.7 ms	22.6 vs 9.3 ms

Checklist

• spread() → one render effect per element (client.ts ~809, the // TODO: make this better). Three reactive nodes per element today; the dynamic-props path costs 2× the static one on hydrate and mount, and spread is the largest share. (spread() creates three reactive nodes per element #3388) — landed in perf(web): spread() creates fewer reactive nodes and accepts a sources array #3419: ref folded into the attribute effect, children stay owned (two nodes with children, one without), sources array; compilers emit the array form for element spreads (feat(compiler): emit the spread/ssrElement sources array for multi-source element spreads #3423, universal feat(universal): spread() with fewer reactive nodes and a sources array; compilers emit it #3424). Browser hydrate on the styled-element shape went from 1.47× behind yak's hand-rolled path to 1.00×.
• Constant-tag Dynamic/dynamic(): when source() is a string that can't change, skip the factory + instance memos, allow a static class baked into a cached template, and take the compiled-JSX element path. Same fix carries runHydrationEvents and namespace correctness. (Constant-tag Dynamic / dynamic() should take the compiled-element path #3387, dynamic() / Dynamic with a string tag: no runHydrationEvents(), namespace ignores parent #3386) — landed as dynamic(source, { static }) + isStatic(o, key) in perf(signals,web): dynamic(source, { static }) and isStatic(o, key) #3471: no memo per instance, the tag goes straight to ssrElement / the compiled element path, and a library decides per instance from the prop's descriptor (isStatic sees through merge/omit layers), so a literal as="a" at the call site takes the static path while a reactive as keeps the memo. dynamic() / Dynamic with a string tag: no runHydrationEvents(), namespace ignores parent #3386 part 1 (runHydrationEvents) fixed in fix: run hydration events after dynamic() spreads a string tag #3396, part 2 (namespace: dynamic() honors xmlns) in fix(web): dynamic() honors xmlns when creating a tag-name element (#3386) #3436; <Dynamic> deprecated in favor of dynamic(). The compiler-lowered <element tag> (Static-tag intrinsic: <element tag={tag}> for elements whose tag is fixed at definition time #3429) stays open as a later question — the runtime path is fast enough that it is a spread-shape question, not a memo one.
• Server merge/omit fast path when every source is a plain object (the rc.8 spread fast path 4e730a9, but on the server), and a predicate / $-prefix form of omit so "drop all $ keys" doesn't require enumerating first. — landed in perf(signals,web,universal,html): merge/omit are always lazy views; consumers read the leaves #3454 (merge/omit always return O(1) lazy views; an omit over a merge flattens to filtered leaf entries; omit(props, key => …) predicate form; truthful getOwnPropertyDescriptor through every layer), chore(solid,web,universal): the runtimes' seams move behind solid-js/internal #3470 (the view protocol consumers walk moves behind solid-js/internal), and the follow-up perf/view-table-on-enumeration (in review): a view's resolved key table is built by enumeration or after 16 reads, never on the first read, and ssrElement walks a view's entries instead — profiled on the Kobalte-shaped chain, a third of SSR time was the table code and its garbage. Same-process A/B: SSR chain 8.2× → 5.8× the compiled floor. Original design note follows. CPU profile of the tabs SSR case (styled(Component) + omit + spread): merge 18%, omit 10%, yak's copyProps 11%, GC 16% (mostly from the same allocations); Solid's rendering proper (ssrElement, escape, resolveSSRNode, ssr) ~7%; component machinery ~2%. Each Tab builds a chain of three or four Proxies and every consumer enumerates through the traps. Direction: omit carries its skip-set on the $SOURCES brand and ssrElement/spread/merge walk branded views directly, never through traps; the Proxy stays only for direct property reads.
• ssrElement with skip rules / extra sources, or a lower-level serializer, so a library doesn't have to materialize getter-bearing props just to have them walked again (yak measured −18.9% HTTP throughput on that path). — landed in feat(web): ssrElement accepts an array of prop sources and a skip predicate #3418: ssrElement(tag, sources[], children, needsId, skip?), single walk, later wins, winner read once. On dynamic-prop shapes ssrElement is now within 3–23% of yak's serializeElement (was 2–3× behind); the fully static shapes remain 3× behind because yak string-concats those at build time (not our gap).
• Hydration per-element overhead: hydrate is ~1.7× mount for 1000 static buttons (15.7 vs 9.3 ms at 4× throttle). Profile gatherHydratable / registry build and per-element getNextElement, and stripTextSeparators + [...childNodes] in claimInitial on large flat lists (interacts with SSR emits <!--!$--> between adjacent memo/function items even when they resolve to elements #3383 separators). — the styled-element shape closed with perf(web): spread() creates fewer reactive nodes and accepts a sources array #3419 (1.47× behind yak's path → 1.00×), and yak reports the whole PR's hydrate on rc.8 "inside the floor" with rc.8's spread fast path alone worth ~12 points to their runtime. The composition cases (tabs, multifile: 0.45× React on rc.8's predecessor) have not been re-measured since; re-run on rc.9 before profiling further.
• Cheap "props plus one key" for the theme case (merge(props, { theme }) allocates a merge object per instance; Object.create(props) was slower). — since perf(signals,web,universal,html): merge/omit are always lazy views; consumers read the leaves #3454 a merge() is one record + one Proxy with no descriptor copy, the same shape as the shared-handler view yak settled on (withTheme / viewTraps, 279317a6); needs the harness on rc.9 to confirm it is within noise before closing.
• Re-run the harness after each item (gated on an rc.9 so yak targets published packages); when a primitive is within noise of yak's version, open the corresponding follow-up on @yak/solid to delete the duplicate. — blocked on rc.9 (Release RC packages (rc) #3399). Faster @yak/solid runtime for unfolded styled components DigitecGalaxus/next-yak#644 merged 2026-09-15 on rc.8, so none of perf(signals,web,universal,html): merge/omit are always lazy views; consumers read the leaves #3454 / perf(signals,web): dynamic(source, { static }) and isStatic(o, key) #3471 / the table follow-up is in what it measures. Its final experiment table (rc.8 vs rc.6) is the list to re-run: see the status comment below.

Not our gap

Definition-time chain flattening, static-class collection, choosing the renderer when the module loads, caching template parts: that is yak doing at runtime what our compiler does at build time. No Solid change removes it.

Landed alongside (correctness surfaced by the same audit)

• SSR emits <!--!$--> between adjacent memo/function items even when they resolve to elements #3383 <!--!$--> separators decided on resolved values → fix(web): decide SSR text separators on resolved values #3394 (+ perf(web): fold the SSR walker entry wrappers into the walkers #3430 recovers the ~2% SSR cost of the walker split)
• ssrElement emits style="" / class="" for nullish values #3382 empty style=""/class="" → docs: correct createContext guidance for server rendering #3395
• merge() re-flattens through a stale $SOURCES and discards the object's own properties #3384 merge() stale $SOURCES → fix(signals): treat a plain merge() result as an ordinary source (#3384) #3401
• renderToString disposes its root via setTimeout; graphs are retained across synchronous renders #3385 renderToString deferred dispose → fix(web): dispose renderToString's root synchronously, committing the response head first (#3385) #3422
• dynamic() / Dynamic with a string tag: no runHydrationEvents(), namespace ignores parent #3386 (1) runHydrationEvents after dynamic() string tag → fix: run hydration events after dynamic() spreads a string tag #3396

Versus React (the part that matters more than parity with yak's PR)

Element-dense cases: Solid 1.5–4× faster than React on SSR, hydrate and mount. Component-composition pages (tabs, multifile-composition): React ~4× faster on SSR and ~2× on hydrate. The SSR half is the props-plumbing item above, not Solid's renderer; the hydrate half is being profiled.

[ryansolid]

Status, 2026-09-15. Checklist updated above. Landed since the last update: #3454 (lazy merge/omit views, predicate omit), #3470 (solid-js/internal), #3471 (dynamic(source, { static }), isStatic), #3436 (dynamic() honors xmlns), #3422 (renderToString disposal), #3430 (walker). In review: perf/view-table-on-enumeration — the resolved key table of a view is built by enumeration or after 16 reads, never on the first read, and ssrElement walks a view's entries (SSR polymorphic chain 8.2× → 5.8× the compiled floor, same-process A/B; DOM lane flat; signals props-chain −5…−17%).

Where that leaves the SSR profile of the Kobalte-shaped chain: no single item left. Element serialization ~35% (part of it is the compiled floor's own cost), ~10% per component layer (createComponent + owner + hydration key + the compiled props literal with a closure per getter — the lazy-props model), GC ~16%.

Re-check of DigitecGalaxus/next-yak#644, merged this morning on rc.8 (35 commits after our comment; the author's own experiment table, rc.6 vs rc.8). Sorted by whose gap it is:

Ours, and answered by code that is on next but not in rc.8 — needs the harness on rc.9:

• "server data properties for component targets: 1.77× (omit/merge unchanged)" — perf(signals,web,universal,html): merge/omit are always lazy views; consumers read the leaves #3454 + the table follow-up are the direct answer.
• "shared proxy view for theme/attrs instead of merge" (279317a6) — same shape merge() now has; the "props plus one key" item above.
• "no dynamic() for the four html-or-svg tags: rc.8's dynamic() is synchronous and html-only" — xmlns (fix(web): dynamic() honors xmlns when creating a tag-name element (#3386) #3436) and { static } (perf(signals,web): dynamic(source, { static }) and isStatic(o, key) #3471).

Ours, still open:

• "direct writer instead of ssrElement over the target props: 1.6–1.9× (plain values)". Their experiment fed ssrElement a materialized copy (copyProps); the rc.8 array form ssrElement(tag, [props, computed], children, needsId, skip) from feat(web): ssrElement accepts an array of prop sources and a skip predicate #3418 was not one of the variants. To evaluate: a yak variant on that form vs their serializeElement, on rc.9.
• "run-once server memo instead of createMemo: 1.3×". The server has a sync fast path (createSyncMemo, options.sync) that the compiler and our flow controls use; sync?: boolean is on MemoOptions but undocumented, so a library can't know to ask for it. To evaluate: document sync, measure createMemo(fn, { transparent: true, sync: true }) against their once() — it still allocates an owner for id plumbing, so it may not close fully.
• "_hk per element: 2.26× React's bytes; a positional claim would need Solid". Correct, and out of this tracker's scope — it is a hydration-design question (attribute keys vs positional claiming), not a primitive. Noting it so it isn't lost.

Not our gap (build-time knowledge the runtime carries): generated class names need no escaping (escape already bails on a clean string in one regex scan); joining plain children without a hole (ssr() already inlines the string path — the gap is their skipping the call, not the call); the children-only path; baked object attrs. Same category as the "Not our gap" section above.

Parity checks that came out clean: void tags close with " />" here too (an unquoted _hk would swallow the slash); textarea value-as-content matches #3286; their $PROXY → receiver identity is what spread/mergeSources require and stays valid under #3454 (a foreign proxy is walked through its traps as SOURCE_PROXY); child getters read once, first child key only, none on a void tag — the #3313 rule.

Next: rc.9, then the harness with the three "needs rc.9" rows and the two open evaluations.

— Claude via Cursor

[ryansolid]

Re-evaluation on next + #3475 against the merged yak runtime (DigitecGalaxus/next-yak@eadda37)

The harness now has a solid-merged lane and a merged-prim overlay: the merged styled.ts with each hand-rolled piece behind an esbuild define, so one Solid primitive at a time is swapped in and measured. All lanes verify byte-identical (modulo _hk). Quiet machine, per-lane processes, median of 3×5 rounds; lane-to-lane noise on identical code is ±8%.

Merged runtime vs React (stock rc.8 → next): element-dense cases unchanged at 3–5.5× React (yak bypasses Solid there); multifile-composition 0.27× → 0.43×; tabs 0.28× → 0.44×; polymorphic-chain (pure Solid, no yak code) 0.08× → 0.25× (42.8k → 141k inst/s). Geomean 1.60× → 1.71×.

Each primitive swapped in alone (merged ÷ flagged lane, >1 = the hand-rolled code is faster):

flag	primitive	geomean	where it bites
__PRIM_MEMO__	createMemo(fn, { transparent, sync }) for once()	0.99×	parity
__PRIM_THEME__	merge views for the theme/attrs proxies	1.03×	parity
__PRIM_PROPS__	merge(omit(props, skip), …) for component targets	1.03×	1.23× multifile-composition, 1.35× tabs (was 1.77× on rc.8)
__PRIM_SSR__	ssrElement(tag, [sources], undefined, true, skip) for the direct writer	1.27×	1.6–2.1× on dyn-*, 1.43× multifile-shop

So two of the four hand-rolled pieces buy nothing on next; the server sync memo is at parity with a run-once closure and just needs documenting. Remaining Solid-side gaps: ssrElement for element targets (largest), and the merge/omit view for component targets on composition shapes.

Why polymorphic-chain is still 4× behind React — CPU + allocation profile under renderToString: Solid allocates 16 KB per instance on next (35.8 KB on rc.8) vs 1.4 KB for React, and GC is 21% of CPU vs 3%. Per instance: ~5 KB omit views (omit-over-merge-over-omit flattening allocates a record per flattened leaf plus a combined hidden-key array per already-omitted leaf; leaf counts 2, 4, 5, 6 across the four layers), ~3–4 KB compiled props literals (an object with ~12 accessor closures per component call), ~2.7 KB merge views, ~2.5 KB memos (Show + two in server Dynamic; Show's and Switch's condition memos are on the full async-capable path, not the sync one), ~2–3 KB ssrElement strings. Not yak-related: compose-3 is 105 B/instance vs React's 178 B.

Candidate follow-ups, in order: server createMemo lean-until-async (one change covering Show/Switch/dynamic and every user memo in SSR); ssrElement element path (plain-text child shortcut, cheaper later-source ownership check); slimmer omit/merge flatten records; server dynamic() sync-first path; document sync on server createMemo.

— Claude via Cursor