Reduce GC churn in transcription worker (5026 GCs / 707ms in 30s)

[ysdede]

Trace: Trace-20260213T014231.json (summary in trace_analysis_summary.json)

Evidence

• GC total: 6518 collections, 1006.4ms total
• Dedicated worker TID 19820: 5026 GCs, 707.3ms total, max 10.1ms

Impact

• Background worker spends significant time in GC, increasing tail latency for transcription and VAD.

Hypothesis

• High-frequency allocation in worker pipelines (window building, result objects, typed arrays) during steady-state streaming.

Candidate locations

• src/lib/transcription/transcription.worker.ts (per-window ASR result mapping + postMessage payloads)
• src/lib/transcription/TokenStreamTranscriber.ts (per-chunk allocations and object spreads)
• src/lib/audio/mel.worker.ts (new arrays in getFeatures)

Actions

• Pool/reuse typed arrays and result objects; avoid per-chunk object literals where possible.
• Use Transferables for large buffers to reduce cloning and associated allocations.
• Add allocation counters or a simple performance.memory sampling in worker to validate.

Acceptance

• Worker GC total time reduced by at least 50% in a 30s trace.
• Fewer long GC pauses (>5ms) observed on worker 19820.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• v2 optimizations: Reduce GC pressure in Transcription Worker #107

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[ysdede]

Additional candidate: BufferWorkerClient allocations

src/lib/buffer/BufferWorkerClient.ts: writeEntry, writeBatch, and writeAudio each do const copy = new Float32Array(data) (and postMessage with transfer). So every producer call allocates. Worker-36712 has 639 receives in the same trace; reducing copies here should help.

• Prefer writeBatchTransfer (or a transfer-only API) from callers that can give up ownership (e.g. mel features, audio chunks).
• Where a copy is required, consider a small pool of Float32Arrays by size bucket and reuse instead of new Float32Array(data) every time.

[ysdede]

From Feb 2026 trace. The Codex perf sweep (commit 3a46116) landed UtteranceBasedMerger allocation cleanup and AudioEngine bar-level optimizations. Worker GC pressure needs fresh profiling to see current state.