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>
irisandClaude Opus 5
5b9941cfaa