Timeline size and platforms

A timeline holds at most 200,000 moments (and at most 200,000 durations and 200,000 relationships) on every platform. A self-hosted server can raise or remove that limit for its own timelines with TIMELINE_ENTRY_LIMIT (Timeline size); the offline HTML file and the desktop app's .och files keep it. Within that limit, the platforms differ in how responsive large timelines feel. The data below comes from the capacity benchmarks.

Which platform to use

The comfortable sizes come from the UI benchmarks on GitHub's runners: up to them, every interaction meets its budget.

Why the browser is different: guest editing and the offline HTML file keep the whole timeline in the page. Opening parses and indexes every moment, and every redraw summarizes them in JavaScript. The desktop app and the platform keep timelines in a database and read only what is on screen, so their costs grow far more slowly. Memory is rarely the problem: an open timeline takes about 0.6 KB of browser memory per moment (about 115 MB at 200,000).

Signed-in users who edit a timeline kept only in the browser (imported, and not yet saved to their account) have a draft kept in the browser. Opening such a timeline stores the whole draft once; after that, each change stores only the records it touched, in under 1 ms even at 200,000 moments. The pause after an edit is the redraw.

Advice in the app

The editor suggests another platform when a timeline outgrows the one in use. The advice appears as a notice under the header; it never blocks editing, and dismissing it holds for that timeline.

• Browser: The notice appears when this device measured the timeline as slow, timing what its user waits for, from an input until its result is painted:

  • opening took more than 1.5 s, until the timeline was painted;
  • zooming, panning and pinching, from 1,000 moments: the median of the last five waits from an input until its view was painted exceeded 150 ms. Below 1,000 moments the time goes on drawing, which every platform does in the browser, so another platform would not be faster;
  • keeping a draft took more than 100 ms after each change (signed in, for a timeline kept only in the browser).

  Once measured slow, the notice stays for that timeline, even if later views are quick (a small pan after slow zooming). Without such measurements it appears from 20,000 moments. It offers Export (to open the file in the desktop app), Save to server or Sign in where the browser is connected to a server, a link to the desktop app, and, in the offline HTML file, a link to the platform.

• Desktop app: The notice appears when views of the timeline consistently take more than a second on this computer. It suggests saving the timeline to a server.

• Every platform: The notice appears from 150,000 events (moments or durations) or relationships, since a timeline holds at most 200,000. On a server with a different TIMELINE_ENTRY_LIMIT, the notice appears at three quarters of that limit, and never when the limit is unlimited. It suggests splitting the timeline. On the platform and in the desktop app the count covers moments; in the browser it also covers durations and relationships.

These rules live in src/capacity.ts.

Data

Medians from npm run bench on a 16-core Linux desktop, with Chromium for the browser. "4× slower CPU" throttles Chromium's processor 4×, roughly a mid-range phone.

Platform rows exclude PostgreSQL's indexes and revision history.

A response within 100 ms feels instant, and a task that takes more than a second loses the user's attention. The browser crosses these lines first:

• At full speed, a redraw exceeds 100 ms from about 4,000 moments, and opening exceeds a second from about 14,000.
• With the CPU slowed 4×, a redraw exceeds 100 ms even at 1,000 moments, and opening exceeds a second from about 3,000.

The desktop app opens in about a second at 100,000 moments and more. Its views and saves, and all of the platform's operations, stay well under 100 ms up to the limit.

The Benchmarks workflow reproduces these on GitHub's runners (Actions → Benchmarks), and its report shows them as charts. On a standard GitHub-hosted runner the curves had the same shapes, about 1.3× slower:

There, the browser opens in about a second at 10,000 moments, and in about a second at 1,000 with the CPU slowed. The desktop app opens 200,000 moments in 1.5 s.