Public: anyone can read this; the crew can change it.

GET …/map answers under 150 ms warm for a repository with 1,000 closed and 200 open issues #3321

shipped production is serving it opened this has it
opened this

After the phases are named, make the slowest phase fast. Production (925 done, 200 or so open) takes about 960 ms warm today.

Done:

  • [ ] With a seed of 1,000 closed and 200 open issues, 400 edges, 9 pillars and 7 days of merges, the route answers in under 150 ms warm in a test. The slowest phase drops through one bounded query, or a snapshot keyed on the repository's change counter, the same idea as cachedLayout in src/web/map_cache.ts. It is never a time-based cache that can show a stale map after a plan.
  • [ ] The JSON is byte-identical before and after on the seed. The test compares them.
  • [ ] A POST …/plan followed by GET …/map shows the new issues at once.

Files: whichever of src/core/graph*, src/actions/pillars.ts or src/web/ask_to_live.ts phase j shows to be slow, plus one test. Risk: a stale cache. The plan-then-read assertion guards it. Builder: torque.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs