#41 · Measure capacity and explain which platform suits which timeline size
- timeline-app
- pull request
Step 1 of the capacity work. The advisories are #39 and the per-edit draft pause is #40. ## What this adds - **An "Open a timeline" operation on every backend:** - **Browser (in-memory):** parse, validate, build the index, draw the first frame. - **Desktop (SQLite):** copy and check the file into a baseline, draw. - **Platform (PostgreSQL):** metadata plus the first view. - **`bench/capacity.mjs`:** measures the real editor in Chromium (Playwright), at full speed and with the CPU throttled 4× through the DevTools protocol, which roughly approximates a mid-range phone. - **Open:** import until the fitted view is drawn. - **Redraw:** apply new bounds until drawn. - **Pause after an edit:** the longest gap between animation frames after a rename, signed in, with a browser-only timeline, so it includes the draft save. - **Heap:** after garbage collection. - **Storage:** SQLite file size and PostgreSQL rows per timeline. - **A capacity section in the report:** open, redraw, pause after an edit, and memory or storage. The throttled browser is dashed, and the time charts have reference lines at 100 ms ("feels instant") and 1 s ("keeps attention"), so you can see where each platform crosses them. - **`npm run bench`** includes the capacity measurements, skipping them with a notice when Chromium isn't installed. `npm run bench:capacity` runs them alone. - **The Benchmarks workflow** installs Chromium and now defaults to 1k, 10k, 50k, 100k and 200k moments. - [This branch's run](https://github.com/openchronology/timeline-app/actions/runs/37993885162) finished every size in 30 minutes on a standard runner. - Its report is the `benchmark-report` artifact. - **[docs/capacity.md](docs/capacity.md):** user-facing guidance on which platform suits which timeline size, with the data. It is linked from the README. - The largest seed holds 199,999 moments, so the create benchmark stays within the 200,000 limit; this is what caught the earlier failure. ## Findings (local; the runner was about 1.3× slower, same shapes) | Moments | Browser open | Browser open, 4× slower CPU | Browser redraw | Desktop open | Platform open | |--:|--:|--:|--:|--:|--:| | 1,000 | 0.14 s | 0.48 s | 57 ms | 17 ms | 10 ms | | 10,000 | 0.70 s | 2.6 s | 0.14 s | 0.10 s | 18 ms | | 50,000 | 3.5 s | 13 s | 0.18 s | 0.25 s | 25 ms | | 100,000 | 8.6 s | 34 s | 0.23 s | 1.1 s | 24 ms | | 200,000 | 21 s | 81 s | 0.21 s | 1.1 s | 35 ms | - **The browser is the only platform that strains within the 200,000 limit.** - At full speed, a redraw exceeds 100 ms from about 4,000 moments, and opening exceeds 1 s from about 14,000. - With the CPU throttled 4×, a redraw is over 100 ms at 1,000, and opening exceeds 1 s from about 3,000. - Memory isn't the issue: about 0.6 KB per moment, 116 MB at 200,000. - **The desktop app stays fast:** views take 7–46 ms and saves 2–3 ms. Opening reaches about 1 s at 100,000 moments and more, because the file is copied into a private baseline. - **The platform stays under 50 ms for everything,** up to the limit. - **The pause after an edit** (signed in, browser-only timeline) reaches 0.35 s at 200,000 at full speed and 1.4 s throttled. That's the draft save in #40. The guidance in `docs/capacity.md`: - **Browser on a fast computer:** comfortable to about 4,000 moments, noticeably slow from about 15,000. Then move to the desktop app or the platform. - **Phones and slow computers:** comfortable to about 1,000. Then use the platform. - **Desktop app:** fine to the limit. Suggest the platform for collaboration or slow machines, not for speed. - **Platform:** fine to the limit. Split timelines that approach it. ## Testing - Ran the full suite locally at 1k–200k against PostgreSQL 16 with pgmp, in Chromium. I checked the report in light and dark mode and at phone width. - 180 JS unit tests pass. - The benchmark workflow run above passed on this branch.
Sources
Open #41 · Measure capacity and explain which platform suits which timeline size in the timeline