irisandClaude Opus 5
5b9941cfaa
A page of history landing recomposed every loaded row and everything inside it -- 701 compositions for 148 rows in one of Iris's scrolls, which is four rebuilds of the whole visible transcript, markdown and all. That is what her `waited` at the 90th percentile was: the frame could not start because the thread was rebuilding rows whose content had not changed. Nothing was stopping Compose skipping them except that it could not prove it was safe to. Stability is inferred from a class's fields and a `List` field makes it assume the worst, so `TranscriptItem`, `TranscriptRow` and `ParsedReplies` were all treated as things that might change underneath a composable at any moment. They are not: a row is rebuilt from the transcript rather than edited, two rows describing the same events are equal, and the parse cache is keyed on the text it parsed. Saying so is the whole change. Measured on the emulator over the same scroll: 139 row compositions, and **15** of them rebuilt the message inside. The other 124 skipped straight past the markdown, which is where the cost was. The transcript's own draw came down with it, from 3.1ms mean to 1.2ms. The promise these annotations make has to stay true -- nothing described by them is mutated after it is built. It is not today, and the note on `TranscriptRow` says so where somebody adding a field will read it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>