اگر با یک لپتاپ قدیمی کد میزنید و هر بار اجرای محیط توسعه باعث گرم شدن شدید دستگاه میشود، Rust Glancer دقیقاً برای شما ساخته شده است. این ابزار جدید، کفِ مصرف منابع در اکوسیستم Rust را بازتعریف کرده و مصرف حافظه را برای پروژههای متوسط به زیر ۱۰۰ مگابایت کاهش داده است. این رقم در مقایسه با تقاضاهای سنگین استانداردهای فعلی صنعت، تضادی آشکار است.
به نقل از مستندات پروژه، این سرور زبان (LSP) در ۲۱ اوت ۲۰۲۶ منتشر شد تا جایگزینی بهینه برای استانداردهای فعلی باشد. سالهاست که توسعهدهندگان Rust به rust-analyzer متکی هستند؛ ابزاری قدرتمند اما بدنام که گاهی چندین گیگابایت از رم را میبلعد و فنهای سیستم را به شدت به کار میاندازد. این موضوع برای کسانی که از سختافزارهای محدودی مثل MacBook Pro M1 مدل ۲۰۲۰ با ۸ گیگابایت رم استفاده میکنند، یک مانع جدی است، زیرا فشار حافظه اغلب باعث کند شدن کل سیستم میشود.
Rust Glancer این مشکل را با تغییر بنیادین در نحوه تحلیل کد حل میکند. این ابزار بهجای استفاده از یک پایگاهداده مقیم در رم — شبیه به دفترچهای که برنامهنویس برای دسترسی سریع همیشه باز نگه میدارد — از یک مدل تحلیل «منجمد» استفاده میکند. در واقع، مدل تحلیل کد را یک بار ایندکس کرده و نتایج را مستقیماً روی سیستم فایل ذخیره میکند. هر زمان که ویرایشگر به اطلاعاتی نیاز داشته باشد، فقط دادههای مربوط به همان پرسوجوی خاص را برای مدت زمان آن درخواست از دیسک فراخوانی میکند.
همانطور که در تحلیلهای قبلی ما درباره بهینهسازی ابزارهای توسعه اشاره کردیم، جابهجایی بار محاسباتی از رم به دیسک در محیطهای مدرن، راهکاری کلیدی برای مقابله با سنگین شدن ابزارهای IDE است. این رویکرد بهینهسازی منابع یادآور تلاشهای مشابه در ابزارهای تحلیل کد است؛ برای مثال، بازنویسی هسته Tree-sitter در Rust توانست مصرف CPU را تا ۲۲٪ کاهش دهد تا سرعت پردازش ساختارهای نحوی بهبود یابد.
چرخش در معماری تحلیل
بر اساس مستندات منتشر شده در rust-glancer.github.io، توسعهدهنده این پروژه سه منبع اصلی مصرف حافظه در ابزارهای فعلی را شناسایی کرده است:
- حجم ایندکسگذاری: محیطهای Rust شامل هزاران تابع، ساختار، تریت (Trait) و روابط بین آنها هستند. برای پشتیبانی از قابلیتهایی مثل «یافتن تمام ارجاعات»، هر بدنه تابع و هر دستور باید تحلیل شده و در حافظه نگه داشته شود.
- پایگاهداده Salsa: رویکرد پرسوجوی افزایشی که در rust-analyzer استفاده میشود، بهطور ذاتی به رم وابسته است. این ساختار باعث میشود انتقال بخشهایی از دادهها از رم به حافظههای ذخیرهسازی دیگر بسیار دشوار باشد.
- درختهای نحو Rowan: اگرچه Rowan اجازه میدهد فقط بخشهای تغییر یافته فایل بازخوانی شوند (Partial Invalidation)، اما نمایش درختی آن باعث تکهتکه شدن شدید حافظه (Memory Fragmentation) میشود. این یعنی مقدار رمی که از سیستمعامل گرفته میشود، بسیار بیشتر از مقدار واقعی رم «استفاده شده» است.
Rust Glancer با تبدیل تحلیل به یک دارایی قابل استفاده مجدد روی دیسک، این مشکلات را برطرف میکند. نتیجه این است که پس از هر بار ریاستارت، هیچ زمانی برای ایندکسگذاری مجدد تلف نمیشود؛ اگر یک پروژه یک بار ایندکس شده باشد، شروع مجدد ویرایشگر نیازی به تحلیل دوباره ندارد. توسعهدهنده اشاره میکند که اگرچه برخی بهینهسازیها در مدل Rowan ممکن است، اما مشکلات اصلی پیامد معماری rust-analyzer است که سرعت را بر حافظه اولویت داده بود.
بنچمارکهای عملکردی
در تستهای رودررو، Rust Glancer کارایی ثابتی را در نسلهای مختلف سختافزار نشان داد:
MacBook Pro M4 Max (۲۰۲۵)، ۳۶ گیگابایت رم:
- Rust Glancer: ۵ ثانیه (ایندکس پایه) / ۸ ثانیه (ایندکس کامل)
- rust-analyzer: ۶ ثانیه (ایندکس پایه) / ۱۳ ثانیه (ایندکس کامل)
MacBook Pro M1 (۲۰۲۰)، ۸ گیگابایت رم:
- Rust Glancer: ۶ ثانیه (ایندکس پایه) / ۹ ثانیه (ایندکس کامل)
- rust-analyzer: ۷ ثانیه (ایندکس پایه) / ۱۴ ثانیه (ایندکس کامل)
موازنه فنی و هزینهها
این بهینگی بدون هزینه نیست. از آنجا که بارگذاری و تبدیل دادهها (Deserialization) از دیسک کندتر از خواندن از رم است، این ابزار برای زمان تایپ فعال از «تحلیل سطحی» (Shallow Analysis) استفاده میکند. در این حالت، ابزار از ایندکس کامل قبلی استفاده کرده و هنگام فشردن کلیدها، فقط بدنه تابع فعلی را تحلیل میکند.
این یعنی ایمپورتها، ساختارها یا تریتهای جدید تا زمانی که کاربر سند را ذخیره نکند، بهطور کامل ایندکس نمیشوند. توسعهدهنده معتقد است این تأخیر اندک در دقت در حین تایپ فعال، در برابر صرفهجویی عظیم در رم، یک موازنه قابل مدیریت و پذیرفتنی است.
قابلیتهای کلیدی
با وجود پروفایل سبک، این پروژه برای استفاده روزمره آماده است و شامل موارد زیر است:
- خط لوله ایندکسگذاری: یک خط لوله کامل که شامل سیستم استنتاج نوع (Type Inference) و یک حلکننده تریت است.
- حلکننده تریت: ادغام با Chalk که یک موتور تخصصی و واقعی برای حل تریتهاست. این موتور جایگزین روشهای ابتدایی قبلی مانند تطبیق هدرهای impl و هندلرهای تخصصی برای تریتهای std شده است.
- اکشنهای LSP: پشتیبانی از قابلیتهای استاندارد مانند پرش به تعریف (Goto Definition)، نمایش اطلاعات در هاور (Hover)، نشانگرهای داخلی (Inlay Hints) و تکمیل خودکار (Completions).
- بهینهسازی برای گردشکارهای عاملمحور: استفاده از یک ناظر فایل (File Watcher) سفارشی و تغییر اولویت برای تغییرات خارج از ویرایشگر. این کار از ایندکسگذاریهای مکرر و جابهجایی آزاردهنده Inlay Hintها که معمولاً هنگام ویرایش کد توسط عاملهای هوش مصنوعی (AI Agents) در rust-analyzer رخ میدهد، جلوگیری میکند.
مسیر توسعه و نقش هوش مصنوعی
این پروژه طی چهار ماه از یک ابزار ساده شبیه ctags برای Rust به یک LSP کامل تبدیل شد. توسعهدهنده که هفت سال تجربه مهندسی حرفهای Rust دارد و پیش از این در پروژههای rustc، clippy و rust-analyzer مشارکت داشته، برای تسریع این روند بهشدت از مدلهای زبانی بزرگ (LLM) استفاده کرده است.
با این حال، این فرآیند یک «کدنویسی حسی» (Vibe Coding) نبود. هر درخواست تغییر (Pull Request) بهصورت دستی بررسی و تأیید شد و برخی از Diffها بیش از ۱۰ هزار خط کد داشتند. توسعهدهنده توصیف میکند که در یک چرخه از پیادهسازی یک ویژگی، دنبال کردن پیشنهادهای LLM، شناسایی نقصهای طراحی و صرف گاهی یک هفته زمان برای اصلاح آن نقصها حرکت کرده تا کد قابل نگهداری باقی بماند.
نقاط عطف توسعه شامل موارد زیر بود:
- گسترش ماکروهای اعلامی: استفاده مجدد از زیرساخت rust-analyzer برای مدیریت ماکروهای پیچیده.
- موتور استنتاج نوع: پیادهسازی سیستمی که پیوندهای نوع مرتبط را در یک جدول استنتاج بزرگ ردیابی میکند تا انواع را در مکانهای مختلف حل کند.
- پشته پروفایلینگ: یک پشته سفارشی که عملکرد و مصرف حافظه را بهصورت بومی (با ردیابی اشیاء تخصیصیافته) و از طریق jemalloc اندازهگیری میکند. این سیستم شامل بنچمارکهای CI برای مقایسه مستقیم Rust Glancer با rust-analyzer است.
از Ctags تا LSP
انتقال از یک ایندکسکننده ساده به LSP کامل بهدلیل نیاز به پشتیبانی از کدهای واقعی Rust رخ داد. توسعهدهنده در ابتدا هدفش یک رویکرد «ctags هوشمند» بود که بر کتابخانههای نحو، نمایشهای داخلی و نقشههای تعریف تمرکز داشت. اما تمایل به داشتن Inlay Hintهای بهتر، منجر به چرخهای از افزایش پیچیدگی شد.
برای پشتیبانی از یک خط کد بهظاهر ساده مثل vals.iter().copied().map(|v| v * 2).collect()، پروژه مجبور شد چندین مکانیزم پیشرفته را پیاده کند:
- پشتیبانی از نوع Slice و کلوژرها/تریتهای Fn.
- حل تریتها و پروژکشن نوعهای مرتبط (Associated type projection).
- پشتیبانی از sysroot نسخه Nightly، زیرا خود کتابخانه استاندارد Rust به ویژگیهای نسخه nightly متکی است.
کیفیت کد و ادغام با LLM
توسعهدهنده تأکید میکند که از LLMها بهعنوان متخصصان حوزه طراحی LSP استفاده کرده، نه بهعنوان کدنویسان خودکار. حلقه توسعه شامل ساخت یک ویژگی، تست پیشنهادهای LLM و سپس اصلاح دستی نقصهای معماری بود. این فرآیند بهعنوان نسخهای شتابیافته از توسعه نرمافزار عادی دیده شد که در آن توسعهدهنده از «اشتباهات» معرفی شده توسط AI درس گرفت.
برای حفظ کیفیت، کدها شامل کامنتهای گسترده و مفیدی هستند تا به توسعهدهنده در پیمایش پروژه کمک کنند. او صراحتاً برچسب «clanker» یا «AI slop» (کد زباله AI) را رد میکند و تأکید دارد که کد مسئولیت شخصی اوست و پذیرای نقدهای انسانی است.
نقشه راه آینده
در نسخههای آتی، بهینهسازیهای زیر در دستور کار است:
- مدیریت حافظه: کاهش بیشتر تکهتکه شدن حافظه در حین ایندکسگذاری و رفع مشکل تکهتکه شدن که پس از یک اجرای کامل ایندکس رخ میدهد.
- پشتیبانی از نحو: بهبود استنتاج نوع و گسترش پشتیبانی از سینتکسهای مختلف.
- اکشنهای کد: پیادهسازی فیلدهای تریتهای گمشده و قابلیت ایمپورتهای خودکار.
- پشتیبانی از Proc Macro: یک ایده آزمایشی برای پشتیبانی از ماکروهای رویهای بهگونهای که از اجرای واقعی کد اجتناب شود.
برخی قابلیتها بهدلیل نیاز به اجرای کدهای غیرقابل اعتماد (مانند اسکریپتهای ساخت یا فراخوانی proc macro) پشتیبانی نخواهند شد. همچنین، توسعهدهنده قصد ندارد تا زمان بلوغ پروژه روی نسخه Stable، به حلکننده تریت جدید مهاجرت کند یا ویژگیهای خاص نسخه nightly را در اولویت قرار دهد.
ترفندهای مهندسی داخلی
علاوه بر مدل تحلیل منجمد، چند بهینهسازی سطح پایین دیگر نیز برای پایین نگه داشتن مصرف رم به کار رفته است:
- همترازی تخصیص (Allocation Alignment): همتراز کردن طول عمر تخصیصها برای کاهش تکهتکه شدن حافظه.
- موتور بهعنوان زیرپردازش (Subprocess): مدلی که به مدیریت تکهتکه شدن حافظه کمک کرده و پشتیبانی از پروژههای چند-فضای کاری (Multi-workspace) را موثرتر میکند.
- کش تکهشده (Sharded Cache): سیستمی برای بهینهسازی نحوه ذخیره و بازیابی دادههای ایندکس شده.
Rust Glancer قصد ندارد جایگزین rust-analyzer برای کسانی شود که دقت مطلق در هر ضربه کلید را میخواهند. بلکه هدفش تبدیل شدن به انتخاب اول برای توسعهدهندگانی است که سختافزار محدودی دارند یا همزمان چندین IDE را باز میکنند — وضعیتی که طبق گفته توسعهدهنده، در rust-analyzer میتواند تا ۱۶ گیگابایت رم مصرف کند.
این تغییر نشاندهنده ترندی به سمت ابزارهای «اندازه مناسب» (Right-sized) است. با ورود عاملهای هوش مصنوعی برای انجام کارهای سنگین ویرایش کد، نیاز به یک ایندکس سبک و مبتنی بر دیسک ممکن است بر نیاز به یک سیستم سنگین مقیم در رم پیشی بگیرد.
توسعهدهندگان علاقهمند در حال حاضر میتوانند افزونه VS Code را نصب کرده یا فایل vsix را مستقیماً از مخزن پروژه بسازند.
گام بعدی شما
- اگر از VS Code استفاده میکنید، افزونه Rust Glancer را نصب کنید تا فشار روی رم سیستم خود را بسنجید.
- در پروژههای بزرگ، تفاوت زمان ریاستارت بین این ابزار و rust-analyzer را مقایسه کنید.
- اگر از AI Agentها برای ویرایش کد استفاده میکنید، بررسی کنید که آیا مشکل جابهجایی Inlay Hintها حل شده است یا خیر.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو