کارگو متادیتا را از کتابخانه‌ها جدا می‌کند تا درخت ساخت Rust کوچک‌تر شود

آزمایش جدید سیستم ساخت Rust به یکی از شکایت‌های آشنای توسعه‌دهندگان می‌پردازد: پوشه target حتی زمانی که خود برنامه تغییر نکرده، همچنان بزرگ‌تر می‌شود.

تیم Cargo آماده است -Zembed-metadata=no را زمانی که Cargo و rustc هر دو از کانال نایتلی استفاده می‌کنند، به‌صورت پیش‌فرض فعال کند. این پرچم مانع قراردادن متادیتای کامل Rust در فایل‌های .rlib و .dylib می‌شود. در عوض، این متادیتا در فایل‌های جداگانه .rmeta باقی می‌ماند.

دلیل این تغییر، تکرار داده در فرایند کامپایل است. Cargo در جریان کامپایل از rustc می‌خواهد فایل‌های .rmeta را زودتر تولید کند تا crateهای وابسته بتوانند کامپایل را آغاز کنند. پس از پایان کامپایل کتابخانه، فایل .rlib نیز به‌طور سنتی همان متادیتای Rust را دوباره در خود نگه می‌دارد. این آزمایش نسخه دوم را حذف می‌کند.

اثر اندازه‌گیری‌شده قابل‌توجه است، اما به نوع workload بستگی دارد. در آزمایش تیم، یک ساخت release برای serde از 40.88 مگابایت به 28.68 مگابایت رسید؛ یعنی 29.8 درصد کاهش. ساخت release برای خود Cargo نیز از 807.05 مگابایت به 537.15 مگابایت کاهش یافت؛ یعنی 33.4 درصد. در ساخت‌های توسعه‌ای، وقتی فایل‌های کامپایل افزایشی و اطلاعات اشکال‌زدایی بخش اصلی فضا را مصرف می‌کردند، کاهش کمتر بود.

برای سازندگان ICP·Dev، پیامد عملی این تغییر بیشتر عملیاتی است. اجراکننده‌های CI مبتنی بر نایتلی، کانتینرهای موقت ساخت و workspaceهای محلی ممکن است برای کامپایل‌های تکراری به فضای کمتری نیاز داشته باشند. فایل‌های کوچک‌تر می‌توانند فشار روی دیسک‌های موقت و cacheهای ساخت را نیز کاهش دهند؛ هرچند رفتار cache همچنان به کل زنجیره ابزار و workflow بستگی دارد.

یک مرز مهم وجود دارد: این تغییر یک پیش‌فرض آزمایشی در Cargo نایتلی است و تضمینی برای toolchain پایدار محسوب نمی‌شود. مستندات Cargo، no-embed-metadata را قابلیتی ناپایدار معرفی می‌کنند و نمونه فعال‌سازی آن را با cargo +nightly -Zno-embed-metadata build نشان می‌دهند.

این تغییر برای یکپارچه‌سازی‌های غیرمعمول ساخت نیز اهمیت دارد. توسعه‌دهندگانی که فایل‌های .rlib را به‌صورت دستی link می‌کنند، ممکن است لازم باشد فایل .rmeta متناظر را نیز به rustc بدهند؛ در غیر این صورت، کامپایلر می‌تواند اعلام کند که فقط یک metadata stub در دسترس است. کاربران معمولی Cargo عموماً نباید این فایل‌ها را مستقیماً مدیریت کنند.

کاهش‌های گزارش‌شده از ساخت‌های مشخص serde و Cargo روی x86_64 Linux به دست آمده‌اند؛ بنابراین نتیجه در هر پروژه، profile، target و پیکربندی اطلاعات اشکال‌زدایی متفاوت خواهد بود. تیم می‌گوید هدف این آزمایش جمع‌آوری بازخورد واقعی است تا بعداً مشخص شود طراحی باید تغییر کند، پایدار شود یا کنار گذاشته شود.

درس گسترده‌تر این است که artifactهای ساخت Rust اکنون به‌عنوان محصولاتی جداگانه از کد و متادیتا دیده می‌شوند. اگر این آزمایش از آزمون‌های واقعی عبور کند، Cargo آینده می‌تواند بدون قربانی‌کردن کامپایل افزایشی یا قابلیت اشکال‌زدایی، فضای کمتری مصرف کند.