Compare compiled sources

Memoization in the incident triage app

The same 200-incident app, data and controls: No memoization, Manual memoization, and React Compiler. These are local Chromium lab measurements, not production field telemetry. The compiler arm uses the experimental Oxc integration; results describe this integration and workload, not every React Compiler implementation.

Overview

Manual memoization remains effective in this app: no demonstrated selection-speed winner between compiler and manual, while compiler ships 5.26% more minified JavaScript.

Parentheses show absolute change and percentage against No memoization: negative means fewer bytes or less time, positive means more. Percentages use the unrounded report values, not rounded display cells. A zero reference gives n/a. Each row is its own endpoint; different workloads and protocols are never pooled into a score or ranking.

Manual optimization has lower bundle cost in this workload. Median selection-to-detail DOM at 4x CPU slowdown: 13.6 ms (No memoization); 5.4 ms (Manual memoization); 6 ms (React Compiler). These descriptive timings do not establish a repeatable speed winner. They do not establish equivalent responsiveness, identical memory behavior, or guaranteed gains in every scenario. Compare load, selection and query filtering separately; fewer render-work events do not by themselves demonstrate lower latency.

Six local load repetitions, three Lighthouse audits and twenty warmed trials per interaction in one Chromium process are advisory, not statistical proof or real-user evidence. Paint opportunity is not a guaranteed presentation timestamp. Render-work events use internal React 19.3.0 profiling fiber flags, not a public API; revalidate after upgrades. The Oxc compiler integration is experimental.

Page load

Initial-load production bytes

Normal production builds only. All sizes use decimal kB (1 kB = 1,000 bytes); exact bytes remain in comparison.json. Parentheses are differences against No memoization.

Manifest entry JS, static imports, and attached CSS counted once per file. Source maps, dynamic imports, and profile builds excluded. Bundle bytes do not measure parse time or interaction latency. Separately loaded chunks: No memoization: none; Manual memoization: none; React Compiler: none.

User-perceived load time (UPLT)

UPLT is navigation start to the full 200-row incident table completing two animation frames (a paint opportunity). Fresh isolated contexts, normal production builds, 4x CDP CPU slowdown, six runs covering all six app-order permutations, with each app in each position twice; no network throttling. This is a lab readiness proxy, not a Core Web Vital, guaranteed paint or an input-response metric.

Load memory (normal production builds)

Separate memory-only loads: six repetitions per app, all six app orders, a fresh Chromium browser and context for each load, cache disabled, 1440 x 900 viewport and 4x CPU slowdown. Readiness is the full 200-row table followed by two animation-frame callbacks. No React profiling build, DevTools hook, CPU sampling, or forced GC runs during the load window; memory polling is not added to the existing load/interaction latency runs.

JS heap used is CDP Runtime.getHeapUsage.usedSize (V8 used heap). Embedder heap used is embedderHeapUsedSize (the embedder's garbage-collected heap, including Blink-managed objects); it is not all native/DOM memory or total tab/process memory. CDP reports the corresponding isolate, not just React or a single execution context. Allocated JS heap (totalSize) and array-buffer/external-string backing storage (backingStorageSize) are retained separately in the raw data, not added into a claimed memory total.

Main percentages compare unrounded medians against No memoization; the final compiler-versus-manual column uses manual as its reference. Negative means less memory, positive means more. Min/max show the six runs, not confidence intervals. No memory winner or statistical significance is inferred from this small local sample.

Samples use Runtime.getHeapUsage with a requested 20 ms pause after each response. CDP scheduling and main-thread work can delay samples; timestamps bracket each request in the raw data. The sampled peak is the largest observed counter from navigation start through the readiness snapshot, not the true allocation peak; independent counter maxima need not occur together. Polling adds overhead, and natural GC can occur before any sample. Ready/pre-forced-GC values therefore include GC-timing noise, not just live retained objects.

Observed coverage: 3-3 load-window samples per run, plus the readiness snapshot. The longest load-window/readiness request spanned 387.4 ms; the largest readiness-to-snapshot completion lag was 5.5 ms. Sparse samples cannot rule out larger transient allocations between observations.

The post-GC snapshot follows HeapProfiler.collectGarbage and is a separate retained-memory diagnostic, not a cold-load peak or a leak test. The blank-page snapshot is preserved for context but is not subtracted: navigation can change the isolate. These are cold browser/cache runs, not cold OS/disk caches or real-user device measurements. Raw load-memory samples include all counters, request timestamps, run order and readiness observations. Differences are observations for this workload, not proof of a compiler-caused reduction.

Lighthouse (mobile lab)

Lighthouse 12.8.2, mobile preset with simulate throttling, normal builds. Three fresh Chrome launches per app, alternating order. Scores are 0-100, timings are milliseconds and CLS is unitless. Median metrics are advisory; this protocol is separate from the desktop 4x CDP setup. No memoization raw audit / Manual memoization raw audit / React Compiler raw audit.

Row selection

Path: Platform queue, 67 visible incidents, no detail selected, open INC-0001. Closing the detail is an untimed reset, not a measured endpoint.

Selection responsiveness (normal production builds)

One open/close warm-up followed by 20 warmed trials per app, isolated contexts, rotated app order and 4x CDP CPU slowdown. Timing starts in the browser click handler and stops at the correct detail DOM mutation, then at two animation-frame callbacks. The latter is a paint opportunity, not guaranteed presentation or INP. Playwright latency and React profiling overhead are excluded. Per-trial results remain in selection-latency.json.

Selection component work (profiling builds)

Same selection state and target, separate native-speed profiling builds, one warm-up and medians of three rotated repetitions. Render-work events count completed update work, not milliseconds or DOM mutations. Counts and timings come from different runs and are not directly interchangeable.

Selection inclusive Profiler durations

ACTUAL is React's measured subtree render duration; BASE is an estimate, not an unoptimized comparison run. These are per-run callback medians, not end-to-end selection time. See the expanded methodology below.

Why equal row counts do not mean equal work

Selection update events: No memoization: 67 rows, 67 open buttons, 67 favorite buttons; Manual memoization: 1 rows, 0 open buttons, 0 favorite buttons; React Compiler: 67 rows, 0 open buttons, 0 favorite buttons. Compiler and baseline record the same number of row events here, but the compiler records fewer child-button events. Equal row counts do not mean equal CPU cost or equal DOM work.

In this Oxc output, IncidentList caches the whole mapped result against incidents and selectedId. Invalidating that cache runs the map again. IncidentRow also caches child JSX internally, while the manual outer memo boundary can skip entering an unchanged row. This is a difference in optimization boundaries, not a general inability of React Compiler to achieve memo-like bailouts through caller-side JSX caching.

This explanation is scoped to oxc-transform-react 0.145.0 and the inspected measured output. Compiler App snapshot / Manual App snapshot are post-transform, pre-bundle inspection artifacts; later bundling and minification can change shipped code.

Compiler: list-wide cache

if ($[1] !== incidents || $[2] !== selectedId) {
    let t3;
    if ($[4] !== selectedId) {
      t3 = (incident) =>
        /* @__PURE__ */ _jsx(
          Profiled,
          {
            id: `row:${incident.id}`,
            children: /* @__PURE__ */ _jsx(IncidentRow, {
              incident,
              selected: selectedId === incident.id,
            }),
          },
          incident.id,
        );
      $[4] = selectedId;
      $[5] = t3;
    } else {
      t3 = $[5];
    }
    t2 = incidents.map(t3);
    $[1] = incidents;
    $[2] = selectedId;
    $[3] = t2;
  } else {
    t2 = $[3];
  }

Compiler: cached child JSX inside IncidentRow

if (
    $[6] !== incident.id ||
    $[7] !== incident.severity ||
    $[8] !== incident.title ||
    $[9] !== openIncident
  ) {
    t5 = /* @__PURE__ */ _jsx(OpenIncidentButton, {
      id: incident.id,
      title: incident.title,
      severity: incident.severity,
      onOpen: openIncident,
    });
    $[6] = incident.id;
    $[7] = incident.severity;
    $[8] = incident.title;
    $[9] = openIncident;
    $[10] = t5;
  } else {
    t5 = $[10];
  }

Manual: outer row boundary (ordinary builds define the row-memo flag as true)

const IncidentRow = __ROW_MEMO_ENABLED__ ? memo(IncidentRowImpl) : IncidentRowImpl;

Query filtering

Path: All incidents, 200 rows, All statuses, newest sort and no selected detail. Type A, then AP, then API; clear once to restore the initial list. This path runs independently of selection and favorite edits. Expected rows: 200 / 34 / 34 / 200.

Filtering responsiveness (normal production builds)

One complete warm-up, then 20 warmed cycles per app with rotated order, isolated contexts and 4x CDP CPU slowdown. Timing starts at the native input event before the React handler. AP and clear stop at the correct result-list mutation, followed by two frame callbacks. A and API leave result IDs unchanged: no result-DOM endpoint exists, so DOM timing is null, not zero; their input-to-two-frame opportunity still measures response work. Every endpoint verifies the exact ordered IDs and input value. This synchronous workload has no debounce or pending async search.

Typing uses at least 100 ms pacing between input steps; pacing, Playwright waits, setup and reset are excluded from the measured endpoints. Clearing is one input change, not repeated backspace. Medians and nearest-rank p90 are computed per step across 20 cycles; they are not summed into a workflow total. Raw typed-filtering trials.

Filtering component work (profiling builds)

Fresh default state per profiling run, one warm-up and three native-speed repetitions with rotated order. Clearing remounts 166 previously removed rows; mounts are shown separately and are not counted as render-work update events. Inclusive ACTUAL/BASE callback medians below have diagnostic overhead, not production response timing.

type A (200 rows)

type AP (34 rows)

type API (34 rows)

clear query (200 rows)

Additional evidence

Component work and committed updates (median of 3 runs)

Additional actions come from the existing stateful workflow: mark all notifications read, Platform queue, selection, favorite, bulk search INC-0001, status filter, sort/reset, resolve. The inbox is opened before and closed after the measured notification acknowledgment. The bulk search is not the independent typed-query benchmark above; sort/reset combines four operations. No production latency is claimed for these additional actions.

read notifications

switch queue

favorite incident

search (legacy bulk input)

filter status

sort and reset

resolve incident

Favorite interaction: post-GC JS heap (normal builds)

Separate favorite diagnostic, not load-window memory or selection/filtering allocation. The six UPLT contexts at 4x CPU slowdown also sample Performance.JSHeapUsedSize after forced GC at table readiness and after favoriting INC-0001. Medians of six paired runs; GC is outside load/CPU windows. This is renderer JS heap, not total tab/DOM/native memory or a leak test. Full runs remain in comparison.json.

Favorite interaction: CPU slowdown flame charts

One normal-build favorite trace per app at 4x CPU slowdown. JS-active sampled time excludes V8 (idle) and (program). It is an approximate slice of the sampled window, not end-to-end response time or a render count. Captures include Playwright-triggered work and cannot establish a performance winner. Each chart has its own time scale; compare measured values, not chart widths. Raw profiles open in Chrome DevTools.

No memoization (1942 samples)

Open raw No memoization CPU profile

Manual memoization (1653 samples)

Open raw Manual memoization CPU profile

React Compiler (1757 samples)

Open raw React Compiler CPU profile

What the isolated row-memo experiment adds

The three comparison arms remain unchanged. A separate manual-app experiment toggles only the outer IncidentRow memo wrapper; callbacks, provider values and child memoization stay intact. Removing that wrapper does not reproduce compiler caching inside the row, and cannot predict the benefit of adding memo to the compiler arm.

These results match the main report's source fingerprint and runtime versions; the ON arm's initial-load assets are byte-identical to the measured manual build. Timings are from a separate paired experiment, not extra trials pooled into the three-arm selection comparison.

Whole-build ON-minus-OFF bundle delta: +12 raw bytes / +1 gzip bytes. This is not the isolated library size of React.memo.

Positive savings are OFF minus ON, favoring memo. Thirty paired trials at 4x CPU throttle are grouped into three fresh-context blocks; exploratory Student-t intervals use the three block means, not 30 independent observations. All blocks share one browser/hardware session, and intervals are unadjusted across endpoints. Spanning zero is inconclusive, not equivalence. Frame opportunity is not actual paint; neither endpoint is INP. No automatic winner or timing gate is inferred.

Full row-memo report · Paired raw measurements · Computed ablation summaries

Methodology

Reading the Profiler durations

A render-work event marks an already-mounted component whose React 19.3.0 profiling fiber records PerformedWork in a completed update. A component may contribute events in multiple commits. Events are not milliseconds, equal-cost CPU operations, DOM mutations, or a complete function-invocation count. Only whole-app commits come from the external root React <Profiler>; nested callbacks do not prove the wrapped component ran. These internal diagnostics are not additive or an API guaranteed across React releases.

Root includes App and provider render bodies; shell, toolbar, list, detail, rows, queue items and buttons are inclusive subtree measurements. Overlapping root/parent/child durations are never summed into a total or treated as component self-time.

ACTUAL (actualDuration) is measured subtree render work. BASE (baseDuration) is React's estimated full-subtree render cost from the most recent measured component costs, not a separately measured unoptimized run. It may retain earlier costs and does not undo useMemo/compiler caches or reconstruct uncached calculation costs. BASE minus ACTUAL is not measured savings. Neither is event-handler, layout, paint or end-to-end interaction time.

Whole-app commits count one external root callback per [rootId, rootGeneration, commitSequence]. Initial mounts are outside action windows; action mounts stay separate from update events. Capture waits for semantic outcomes and completed batches in this synchronous workload, not arbitrary future asynchronous work.

In comparison.json, medianDurationMs (ACTUAL) and medianBaseDurationMs (BASE) are independently computed medians across per-run callback medians, not interaction totals. Mount summaries and raw runs stay separate; null means no matching callback was observed, while 0 is a measured zero. Raw durations and lifecycle identities remain in measurements.json. All Profiler durations include diagnostic overhead and are advisory, never CI timing thresholds. Native profiling is separate from normal-build 4x timings and browser sampling diagnostics.

Versions and provenance

Node v22.23.3; Chromium 145.0.7632.6; React 19.3.0; Vite 8.3.0; plugin-react 6.1.1; oxc-transform-react 0.145.0; Oxlint 1.85.0.

200 deterministic incidents; isolated Chromium contexts; one warm-up and 3 rotated profiling repetitions; 6 UPLT runs covering all app orders; initial mounts outside actions, action mounts reported separately from updates

Source, build and measurement fingerprints bind these observations to one capture. Missing or mismatched evidence fails publication rather than mixing results from different runs.