Outcome

With both strands rendered and fully populated (1,002 figure labels + 488 event labels), the double-helix view ran at 4.3 FPS — effectively unusable. Five targeted, measured changes returned it to a usable frame rate and reduced texture memory by 16×, with no loss of visual fidelity at the zoom levels in actual use.

Every change in this record was made on a working copy, verified against the renderer's own counters and Safari's frame profiler, and validated by re-measurement before the next change. No optimization was applied on intuition alone — a discipline that repeatedly corrected wrong initial assumptions about the bottleneck.

A frame-rate collapse under full population

The helix and beta-helix are two interlocking spiral strands. Each figure and historical event is rendered as an individual billboard sprite carrying a baked text label. Singly and lightly populated, the view performs acceptably. With both strands active and full — the heaviest real state — it collapsed:

The root constraint: this is an integrated Apple GPU with unified memory. 5.3 GB of texture data for text labels left no room — the GPU was thrashing texture memory every frame. The starting hypothesis (from an early profiler reading showing 64% "JavaScript" time) was that the animation loop was the bottleneck. That hypothesis was wrong, and proving it wrong was the first job.

Measure, don't guess

Rather than apply plausible fixes, the pass began by instrumenting the live scene. Two read-only console diagnostics were written to extract ground truth the standard profiler view couldn't isolate: a census of sprites, visibility, animation-state, and texture footprint; a microbenchmark of the per-sprite loop; the renderer's draw-call and texture counts; and a CPU-vs-GPU frame-time split.

This discipline paid off by being wrong-proof. Over the course of the pass, the measured data overturned the working hypothesis three separate times:

Five changes, each measured

Applied in sequence, each verified before the next. Ordered as performed; impact varied widely — and one change's main value was disproving a hypothesis rather than gaining frames.

// per-name bake
make2DCanvas(2048, 256)  →  make2DCanvas(512, 64)
font 'bold 160px'      →  'bold 40px'   // same fit, 1/16 the pixels

tex.generateMipmaps = false;
tex.minFilter = THREE.LinearFilter;  // default forces a mip chain

setPixelRatio(Math.min(devicePixelRatio, 2))  →  Math.min(devicePixelRatio, 1.5)

if (frame % 2 === 0) {       // recompute + re-upload at 30fps
  // …40,000-point spiral, both strands…
  helix.geometry.attributes.position.needsUpdate = true;
}

Before and after

Frame-profile evolution

The three dominant GPU costs were removed in turn until a single honest cost remained.

*texImage2D became the visible dominant once overdraw fell — exposing the helix point-cloud upload as its true source. †Absolute ms varies with recording length; drawArrays is now the sole dominant cost as a share of the frame (67.6%).

Waste removed; real work remains

After the five changes, the frame is dominated by a single cost — drawArrays (≈68%), the actual rasterization of ~1,700 transparent blended sprites and the helix point clouds. This is no longer waste; it is the genuine cost of drawing a dense, transparent, two-strand helix. Every cheap inefficiency — oversized textures, dead companion sprites, mipmap generation, redundant geometry uploads — has been removed.

Further gains exist but trade visual quality rather than removing inefficiency, which is the correct point to stop a routine optimization pass:

Diagnostic tooling

Three read-only, self-restoring console probes were written for this pass. They mutate nothing and print copy-paste JSON reports. Retained for future use.