Overhaul README and benchmark documentation#33
Conversation
- Rewrite README: clear positioning (near-native perf in TS), updated benchmark tables with stub/PTY/terminal competitor data, architecture diagram, three usage modes - Add BENCHMARKS.md with full methodology, limitations, and terminal competitor suite (blessed, ratatui) - Expand bench suite: terminal scenarios, PTY mode, framework adapters, worker isolation, ratatui/blessed runners - Committed benchmark artifacts (2026-02-11 full/pty/terminal) - Update docs (index, benchmarks, faq, ink-compat)
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c13c4fecfd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| screen.render(); | ||
| await renderP; | ||
| await new Promise<void>((resolve) => process.nextTick(resolve)); | ||
| await new Promise<void>((resolve) => setImmediate(resolve)); |
There was a problem hiding this comment.
Wait for blessed output drain before ending each iteration
This loop completes an iteration after screen.render() plus two event-loop ticks, but it never waits for createBlessedOutput() to confirm that the write callback has drained; under PTY backpressure (e.g., CI or slow terminals), that allows iterations to advance before frame bytes are actually flushed, which can overlap writes and systematically understate blessed latency / inflate ops/s in the terminal benchmark results.
Useful? React with 👍 / 👎.
| return new Promise<BenchResult>((resolve, reject) => { | ||
| const child = spawn(process.execPath, ["--expose-gc", workerPath, "--payload", payloadB64], { | ||
| stdio: ["ignore", "pipe", "pipe"], | ||
| env: { ...process.env }, |
There was a problem hiding this comment.
Force stub IO mode in isolated workers
runIsolated() inherits the parent environment unchanged, but IO mode is selected from REZI_BENCH_IO; this means a run invoked with --io stub can still execute terminal paths (or fail due missing TTY) whenever the parent shell has REZI_BENCH_IO=terminal, so the CLI flag is not authoritative and benchmark mode can be silently wrong.
Useful? React with 👍 / 👎.
Summary
Test plan