Serializing the reactive graph for hydration: a prototype and measurements

[lxsmnsyc]

Can hydration skip the computes of memos, if the server sends each memo's value with the signals it read? I prototyped this on next and measured it. Short answer: it works, and it halves hydration for pages full of expensive synchronous memos, but in apps built like the 2.0 examples there is little for it to skip.

The branch, with the prototype, a findings document and the scripts to reproduce every number: https://github.com/lxsmnsyc/solid/tree/experiment/graph-hydration/examples/graph-hydration

How hydration works today

• The server serializes the values of async memos only. Hydration adopts the value, and runs the compute once under mocked fetch and Promise (subFetch) to find its dependencies, then throws that result away.
• A synchronous memo has no serialized value, so hydration runs its compute.
• Effects run their computes. The compute of an insert() renders the components inside it and claims their DOM.

The prototype

About 100 lines, mostly reusing the dependency edges that server components already have (server/edges.ts and core/identities.ts). Every change is marked EXPERIMENT(graph-hydration).

• The server turns the edge hooks on for every render. A memo with a plain value sends [value, signal names] under <memo id>#g, if its compute took at least a set time on the server. A read through another memo records that memo's signals.
• The client names its plain signals as the server does, plus a lookup by name. A memo with an entry takes the value and reads the named signals, which links its edges, without running its compute. It computes if a signal is missing, and on every later run.

Results

Chrome with the CPU slowed 4 times, median of 9 loads, Apple M2. Each page is checked with a click after hydration.

A synthetic dashboard of 200 widgets, 4 memos each. "Busy" memos run a loop of 2000 steps.

Memos	Graph	HTML, brotli	Client, until hydrated
cheap	off	4.0 kB	108 ms
cheap	every memo	15.5 kB	116 ms
cheap	memos of 0.02 ms or more	4.05 kB	110 ms
busy	off	4.0 kB	209 ms
busy	every memo	15.4 kB	109 ms
busy	memos of 0.02 ms or more	8.4 kB	112 ms

The example apps of the repository, with the graph off. "Memos with data" are memos that return no nodes, an upper bound on what a graph could skip.

App	Hydration	Memos with data	Memos with nodes	Effects	Trace runs
board	46.8 ms	1.6 ms (3%)	0.0 ms	18.1 ms (39%)	0.5 ms
chat	33.3 ms	3.0 ms (9%)	4.1 ms	14.1 ms (42%)	0.1 ms
hackernews	24.3 ms	4.0 ms (16%)	5.8 ms	9.7 ms (40%)	0.1 ms
notes	33.5 ms	9.3 ms (28%)	4.5 ms	15.2 ms (45%)	0.1 ms
todos-server	21.9 ms	3.3 ms (15%)	0.0 ms	11.8 ms (54%)	0
server-dbmon	33.0 ms	3.9 ms (12%)	6.0 ms	10.4 ms (32%)	0.5 ms

What I take from it

• Trace runs of async memos cost almost nothing: 0 to 0.5 ms a page.
• A cheap memo costs about as much to decode and link as to compute, and its entry triples the HTML. Sending only the memos that were slow on the server keeps the gain for expensive ones and costs nothing for cheap ones.
• In the example apps, most of the "memos with data" are the router's: url returns a URL and matches returns matches that hold components, so neither is plain data, and route preload has to run. Much of their time is a first run that a skip would only move to the first navigation.
• Most of hydration is the insert() that renders and claims the components of the page. A graph cannot skip that.

So I don't think it is worth adding for apps built like the examples. It could make sense as an opt-in for a memo with an expensive compute, such as createMemo(fn, { ssrSource: "graph" }), for apps that hydrate heavy derived data. I'd be glad to hear whether that case comes up, or whether these numbers match what you see in larger apps.

[lxsmnsyc]

What the server sends for the dashboard of the example. Each widget is this component, trimmed of its markup:

function Widget(props: { index: number }) {
  const seed = props.index;
  const [items, setItems] = createSignal(
    Array.from({ length: 6 }, (_, i) => ((seed * 7 + i * 13) % 50) + 1)
  ); // named 001001~0
  const [mode, setMode] = createSignal(seed % 3); // named 001001~1
  const sorted = createMemo(() => [...items()].sort((a, b) => a - b));
  const summary = createMemo(() => {
    const values = sorted();
    const sum = values.reduce((a, b) => a + b, 0) + work(seed);
    return mode() === 0 ? sum : mode() === 1 ? sum / values.length : values[5] - values[0];
  });
  const label = createMemo(() => `${NAMES[mode()]}: ${summary().toFixed(2)}`);
  const bars = createMemo(() =>
    sorted().map(n => "#".repeat(Math.round(n / 10) + work(n))).join(" ")
  );
  // <section> with {label()}, {bars()} and the Run and Mode buttons
}

For two widgets, the server sends each memo's value and the names of the signals it read, under its hydration id plus #g, in the same _$HY.r table as other hydration data. A read through another memo records that memo's signals, so summary lists items through sorted:

_$HY.r["0010010#g"] = [[1,3,14,16,27,40], ["001001~0"]]                  // sorted, widget 0
_$HY.r["0010011#g"] = [101, ["001001~0","001001~1"]]                     // summary, widget 0
_$HY.r["0010012#g"] = ["Total: 101.00", ["001001~1","001001~0"]]         // label, widget 0
_$HY.r["0010013#g"] = ["# ### # #### ######### #########", ["001001~0"]] // bars, widget 0
_$HY.r["0010018#g"] = [[8,10,21,23,34,47], ["001001~0"]]                 // sorted, widget 1

One limit of the prototype that this shows: the signal names come from the server-component edges, <owner id>~<n>, and they repeat across sibling components, since a component has no id of its own. Both widgets name their signals 001001~0 and 001001~1. It works here because each memo is adopted right after its own signals are made, and the lookup keeps the latest signal of a name. A memo adopted later, such as a lazy one or one in a branch that renders after a sibling, would link to the sibling's signals. A real version needs names unique for each component instance.

[ryansolid]

Thanks for prototyping this and measuring it honestly. The breakdown table is the most useful part, and it matches what we've found.

We've profiled hydration on the HN story page (1,406 comments, 652 interactive toggles, Chrome at 4x CPU, sampling profiler, median of 5). The SSR'd SPA spends about 341 ms of script hydrating:

Bucket	ms
Creating the reactive graph (signals, memos, effects)	114
Hydration walk (claimChildNodes, getNextElement)	55
Core helpers (Show, mapArray, hydrated effects)	39
App component bodies	29
Router	23
Other web (insert path, normalize)	29
DOM writes	14

HN does almost no compute, so this doesn't say whether memos are cheap in general. What it shows is the floor a graph can't remove: creating the nodes, walking the DOM and claiming it costs this much even with nothing to compute, and data deserialization (about 46 ms, roughly 1:7) is small next to it. Your example-app table shows the same floor: insert() rendering and claiming takes 32-54%. Those apps are compute-light too, so their 1.6-9.3 ms of data memos tells us they aren't the target, not that the target doesn't exist.

On the mechanism: signals don't get ids in general today. core/identities.ts is only turned on by the server-components client for deferred hydration, and it names signals <nearest owner id>~<n>. That's why your sibling widgets collide. Making it general means naming every signal on every hydrating page, which is a cost paid everywhere for a gain in a few opted-in memos. We also found the counter has to restart wherever child ids restart (reruns, async retries, For rows), or server and client names drift.

A few things a real version would need:

• An explicit opt-in, not a server timing threshold. A timing threshold makes the HTML depend on how fast the server happened to be, so the same page renders differently between requests, which breaks caching and prerendering.
• A rule for memos that create owners or computations. Skipping the compute skips creating them.
• An answer for client signal values that differ from the server's (time, window size, locale). The adopted value would stay stale until a dependency changes.

So I'd want this to prove its worth on a real compute-heavy app, not HN or our examples: something like an analytics dashboard that aggregates on render, a large sorted and filtered table, or chart data transforms. Measure it with the size cost of the ids counted on the same page. If someone has an app like that, I'd love to see the profile. Until then I think the bigger lever is the render and claim cost, which helps every page.