TanStack Table V9 مصرف حافظه رو تا ۹۰ درصد کم کرد
جاوااسکریپت
فرانتاندخلاصهٔ کاملتر
کوین ونکات، یکی از نگهدارندههای TanStack Table، تو این پست توضیح داده که چطور یه رفکتور بهظاهر ساده تو نسخهی ۹ این کتابخونه باعث شده مصرف حافظه برای جدولهای بزرگ تا ۹۰ درصد کمتر بشه. این یعنی جدولهایی که صدها هزار یا میلیونها ردیف دارن (چه صفحهبندیشده و چه مجازیسازیشده) خیلی سبکتر از قبل تو مرورگر اجرا میشن.
بر اساس بنچمارکهایی که تیم منتشر کرده، تو V8 معمولاً قبل از رسیدن به مرز ۴ گیگابایت حافظهی مرورگر، فقط حدود یک تا یکونیم میلیون ردیف جواب میداد. تو V9 همین سقف حافظه، اجازهی پردازش ۱۰ تا ۱۶ میلیون ردیف رو میده؛ یعنی تقریباً ۱۰ برابر بهبود تو مقیاسپذیری. برای یه مثال با یک میلیون ردیف و ۸ ستون، اختلاف مصرف حافظه بین دو نسخه به بیش از ۲.۴ گیگابایت رسیده.
ریشهی ماجرا برمیگرده به اینکه تو V8، وقتی هر شیء row یا cell ساخته میشد، متدهاش (مثل getValue یا getUniqueValues) مستقیم روی همون شیء تعریف میشدن. وقتی میلیونها ردیف داری، یعنی میلیونها کپی از همون توابع یکسان تو حافظه نگه داشته میشه، بهعلاوهی closure scope هر تابع که خودش هم فضا اشغال میکنه.
راهحل V9 استفاده از یه prototype مشترکه: متدهای هر ردیف فقط یکبار ساخته میشن و روی یه prototype کش میشن، بعد هر شیء row با Object.create() همون prototype رو میگیره و فقط دادههای اختصاصی خودش (مثل id یا index) رو جدا نگه میداره:
const row = Object.create(getRowPrototype(table))
row._uniqueValuesCache = {}
row.id = id
row.index = rowIndex
row.original = originalاین کار closure اختصاصی هر شیء رو هم حذف میکنه، چون متد مشترک با this میفهمه داره روی کدوم ردیف کار میکنه. این الگو برای ردیف، ستون، سلول و هدر تکرار شده، ولی بیشترین تأثیر رو روی ردیفها گذاشته چون هم تعدادشون زیادتره هم متدهای بیشتری دارن.
نویسنده میگه این تغییر یه عارضهی جانبی هم داره: دیگه نمیشه متدها رو با destructuring مثل const { getValue } = row گرفت، چون این کار context اصلی رو گم میکنه و متد کار نمیکنه؛ باید حتماً از فرم row.getValue() استفاده کرد. تیم بهخاطر همین شکست سازگاری، این رفکتور رو برای V8 قبول نکرده بودن و گذاشتنش برای نسخهی جدید.
نکات کلیدی:
- TanStack Table V9 با استفاده از prototype مشترک بهجای متدهای اختصاصی روی هر شیء، مصرف حافظه رو تا ۹۰ درصد کم کرده.
- سقف تعداد ردیف قابل پردازش قبل از رسیدن به ۴ گیگ حافظه، از حدود ۱.۵ میلیون تو V8 به ۱۰ تا ۱۶ میلیون تو V9 رسیده.
- عارضهی جانبی این تغییر اینه که دیگه نمیشه متدهای row رو destructure کرد؛ باید مستقیم روی خود شیء صداشون زد.
