perf(chat): batch message height memory so long topics load faster - #227
Merged
Merged
Conversation
… forcing a layout per message Opening a 94-message real topic spent about half its load time in forced synchronous layout. observeMessage and the delayed scan each read offsetHeight and then wrote containIntrinsicSize, one message at a time, so every read after the first write laid the page out again. Registration and the delayed scan now queue the message instead. One animation frame later every queued message is measured first, and only then are the heights written. Pause and resume keep the synchronous path because they need the value at once. Measured on a copy of that history: load went from 7.0s to 3.9-4.6s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RoxyAsahi
marked this pull request as ready for review
October 2, 2026 18:21
RoxyAsahi
marked this pull request as draft
October 3, 2026 00:26
RoxyAsahi
marked this pull request as ready for review
October 3, 2026 12:17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
改动
长话题注册消息和延迟扫描时,逐条读
offsetHeight、写containIntrinsicSize容易产生重复同步布局。改为下一动画帧统一读完高度,再统一写入占位;暂停和恢复仍使用现有同步路径,保留原消息 DOM 和content-visibility。异步任务随优化器生命周期结束:取消观察时移出队列;初始化换根和销毁时清队列、取消已排定帧或回退定时器并更换代次。迟到的旧回调不会消费新任务。写入阶段再次校验连接及归属,可选高度桥接回调重入换根时放弃旧批次剩余数据。
已同步本轮上游
6da3c4d3(包含已合并的 #225)。相对它仅涉及优化器、批处理测试和测试文件白名单,共 3 个文件。没有全量预热、平均高度估算、虚拟列表或渲染流程改写;本 PR 优化加载调度,不宣称解决上游滚动跳动。对抗式检查
4e82b2c3的三个攻击用例失败:销毁没有取消待执行帧、换根继续依赖旧帧、可选桥接回调取消后续消息观察后仍继续写入。本轮a903a038修复。完整应用对比
两个独立完整检出及测试历史副本,相同 Electron、本地流式服务、1200×800 视口,交替运行。基线
6da3c4d3,候选为它加本 PR。时间为进程内页面重新加载至最后一条消息 DOM 插入,不是冷启动或离屏正文全部完成渲染。
94 条首轮候选 4.01 秒、上游 3.86 秒;不保证每次更快。样本量有限。两版均插入预期消息数量并记录高度,未记录页面错误;94 条初始总高度同为 22985px,1000 条同为 132692px。
验证与限制
test:chat-kernel194/194。部分文件重叠,不将数字累加。现有门禁失败已在本轮上游复现:
next-delta缺少preloads/shared/catalog.js;UI 门禁报settings/group-slots.js内联样式;聊天 consumer 门禁报settingsManager.js选择状态所有权断言。不将它们计作通过。隐藏窗口或繁忙主线程可能延迟动画帧,这是调度方案的时序代价。插件完整矩阵、原生 Ctrl+F、系统剪贴板跨消息复制和其他机器尚未全面覆盖;有限测试不保证所有环境零缺陷。滚动探针数据不作为标准 CLS。