readonly属性竟拖垮Letta性能
Are you telling me a readonly property is wrecking my performance?
最近我在排查Letta Desktop的性能问题时，发现随着使用频率增加，产品越来越慢。起初我以为是代码里有低效的循环或未优化的逻辑，但深入分析后才发现，问题出在我强制UI滚动到底部的实现方式上。我原本以为`el.scrollTop = el.scrollHeight`这种写法既简单又高效，毕竟scrollHeight看起来是个只读属性，应该只在渲染时更新。然而事实并非如此，每次访问scrollHeight都会触发布局计算，导致大量消息涌入时性能急剧下降。最终我意识到，很多看似静态的readonly属性其实是动态计算的，不能想当然地认为它们性能无忧。我的解决方案是直接用一个大数代替精确计算，既避免了频繁布局，又达到了滚动到底部的效果。
我原本以为readonly属性总是性能友好，但事实是，很多属性看似静态，实则动态计算，尤其在明显会随事件变化的情况下更需谨慎。
- 有评论者指出 Zig 因无隐藏控制流更利于 AI 理解代码上下文，而 Rust 的 Traits 机制增加了复杂度，导致部分开发者更倾向用 AI 编写 Zig 代码而非手动修改。
- 多位开发者亲历过类似性能陷阱，指出在循环中同时修改布局（如 style.height）和读取布局属性（如 offsetHeight）会强制浏览器多次重排，应通过批处理或分离读写来避免。
- 有观点反驳原文对 readonly 属性的归因，认为性能瓶颈更可能源于 Firefox 对 field-sizing: content 支持不足导致的 JS 频繁重绘，或 let/const 的 TDZ 运行时检查开销。
- 针对 Bun 从 Zig 重写到 Rust 的争议，评论认为这并非单纯的技术选型，而是开发者试图隐藏所有代码逻辑以避免人类阅读，与 Zig 强调的“无隐藏控制流”理念背道而驰。
- 有从业者强调在架构层面推荐 readonly 是为了封装和不可变性，但在高频渲染场景下，打破抽象以换取性能是合理的权衡，关键取决于该屏幕对用户流程的重要性。