‏scrollHeight چطور پرفورمنس رو کند می‌کنه

نویسنده می‌گه داشته یه مشکلِ پرفورمنسِ کلاسیک تو Letta Desktop رو بررسی می‌کرده: هرچی استفاده بیشتر می‌شد، محصول کندتر. اولش فکر کرده حتماً یه حلقه‌ی طولانی یا کدِ بهینه‌نشده مقصره، ولی بعد فهمیده ریشه‌ی ماجرا اصلاً به منطقِ کدش ربط نداره؛ به یه فرضِ غلط برمی‌گرده — نحوه‌ای که موقع رسیدنِ پیام جدید، UI رو مجبور به اسکرول به پایین می‌کرده.

کاری که می‌کرده این خطِ ساده بوده:

el.scrollTop = el.scrollHeight;

به‌نظر معقول و سبک میاد. نویسنده می‌گه از رو مشخصاتِ scrollHeight این‌طور برداشت کرده بوده که این پراپرتی ثابته و فقط موقعِ paint به‌روز می‌شه، نه موقع خوندنش. ولی اشتباه می‌کرده: منطقی‌تره که مرورگر این مقدارو موقعی که کاربر می‌خوادش حساب کنه، نه این‌که هر بار المان تغییر کرد ذخیره‌ش کنه.

نویسنده به پیاده‌سازیِ Chromium اشاره می‌کنه که تو getterِ scrollHeight تابعی به اسم UpdateStyleAndLayoutForNode رو صدا می‌زنه؛ یعنی همون لحظه‌ی خوندن، style و layout دوباره محاسبه می‌شن. حالا چون scrollHeight با هر پیام جدید عوض می‌شه، اگه کلی پیام پشت‌سرهم استریم بشه و مدام لازم باشه به تهِ لیست اسکرول کنی، همین محاسبه‌ی مکررِ layout کارو کند می‌کنه.

درسی که می‌گیره اینه که پراپرتی‌ها می‌تونن دینامیک باشن — مخصوصاً وقتی واضحه که با اتفاق‌افتادنِ چیزی تغییر می‌کنن — و این‌طور نیست که پراپرتیِ readonly لزوماً سبک باشه. راه‌حلِ خودش هم به‌جای محاسبه‌ی دقیقِ scrollHeight این بوده که به scrollTop یه عددِ خیلی بزرگ بده؛ چون مقدار به‌هرحال به کفِ ممکن محدود (clamp) می‌شه و به نتیجه‌ی یکسان می‌رسه بی‌این‌که layout رو مجبور کنه.

نکات کلیدی:

• خوندنِ scrollHeight تو مرورگر محاسبه‌ی دوباره‌ی style و layout رو مجبور می‌کنه
• موقع استریمِ سریعِ پیام‌ها و اسکرولِ مکرر به پایین، همین باعث کندی می‌شه
• پراپرتیِ readonly لزوماً کم‌هزینه نیست؛ می‌تونه لحظه‌ی خوندن محاسبه بشه
• راه‌حل: به‌جای scrollHeight یه عددِ بزرگ به scrollTop بده که خودش clamp می‌شه