読み取り専用プロパティがパフォーマンスを低下させているって本当ですか？

読み取り専用プロパティがパフォーマンスを低下させているって本当ですか？ 投稿日: 2026年7月9日 • 93ビュー 最近、Letta Desktopのパフォーマンス問題の調査に深く入り込んでいました。話はいつもの通りで、使用量が増えるほど製品は遅くなるというものでした。これは私にとって明らかで、おそらく長時間のループや最適化されていないコードのせいだろうと思っていました。しかし、私が気づいたのは、実際の問題は私のコードとは全く関係がない（まあ、まだ関係はありましたが、それは誤った仮定に基づいていたのです）ということでした。問題は、新しいメッセージが届いたときにUIを強制的に下にスクロールさせていた方法にあったのです。ご覧の通り、私は簡単なスクリプトを使っていました： el.scrollTop = el.scrollHeight; これは妥当で、パフォーマンスも良いように思えますよね。scrollHeightの仕様を見ると、このプロパティは静的で、アクセス時ではなくペイント時にのみ更新されるように見えます。もちろん、私は間違っていました。これはパフォーマンスが良くありません。要素が変更されるたびにプロパティを設定するのはなぜでしょうか。ユーザーが要求したときに計算する方が理にかなっています。問題は、新しいメッセージが来るたびにscrollHeightは常に変化し、大量のメッセージがストリーミングされてきて常に一番下までスクロールする必要がある場合、それは私たちを遅くするということです。 int Element::scrollHeight() { if (!InActiveDocument()) return 0; GetDocument().UpdateStyleAndLayoutForNode(this); if (GetDocument().ScrollingElementNoLayout() == this) { if (GetDocument().View()) { return AdjustForAbsoluteZoom::AdjustInt( GetDocument().View()->LayoutViewport()->ContentsSize().Height(), GetDocument().GetFrame()->PageZoomFactor()); } return 0; } if (LayoutBox* box = GetLayoutBox()) { return AdjustForAbsoluteZoom::AdjustInt(box->PixelSnappedScrollHeight(), box); } return 0; } (ここにあるのはChromiumの実装です) さて、もし逆の順序で実装されていたとしても、おそらく同じ問題があったでしょうが、私にとっては、読み取り専用プロパティは一般的に常に非常にパフォーマンスが良いだろうと勝手に思い込んでいました。本当に伝えたいアドバイスはこれです：プロパティは動的になり得ます。特に、何かが起こったときに変化するような、明らかに動的なものです。スクロールの問題に対する私の解決策は、正確なscrollHeightを計算しようとする代わりに、非常に大きな数値を設定することでした。どうせ上限があるからです。