رژیم دیسکی Cargo در نایتلی: چرا Rust فراداده را از کتابخانه‌ها جدا می‌کند

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

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

با غیرفعال‌شدن جاسازی فراداده، rustc فراداده کامل را در فایل‌های جداگانه .rmeta نگه می‌دارد و داخل artifactهای .rlib و .dylib فقط فراداده‌ای کوچک و واسط باقی می‌گذارد. مستندات ناپایدار Cargo این روش را قابلیتی برای صرفه‌جویی در دیسک معرفی می‌کنند و امکان اجرای دستی آن را با cargo +nightly -Zno-embed-metadata build نشان می‌دهند.

میزان صرفه‌جویی به نوع profile وابستگی زیادی دارد. در آزمایش منتشرشده تیم Cargo، یک build از serde در حالت release، بدون کامپایل افزایشی و بدون اطلاعات دیباگ، از ۴۰٫۸۸ به ۲۸٫۶۸ مگابایت رسید؛ یعنی ۲۹٫۸ درصد کاهش. یک build توسعه‌ای پیش‌فرض، که artifactهای incremental و اطلاعات دیباگ در آن غالب‌اند، از ۱۷۹٫۷۰ به ۱۷۱٫۲۹ مگابایت کاهش یافت؛ یعنی ۴٫۷ درصد. تیم Cargo همچنین در بهترین حالت برای build خود Cargo حدود ۳۳ درصد کاهش گزارش کرده است.

این تفاوت برای CI و رایانه‌های توسعه‌دهندگان مهم است. این آزمایش بیشترین ارزش را برای buildهای release تمیز، workspaceهای بزرگ و محیط‌هایی دارد که cache artifactها فضای قابل‌توجهی اشغال می‌کند. در مقابل، در یک پوشه debug معمولی، فایل‌های incremental و نمادهای دیباگ ممکن است آن‌قدر بزرگ باشند که اثر این تغییر محدود بماند.

برای ابزارهای سفارشی نیز یک مرز فنی وجود دارد. بیشتر buildهایی که مستقیماً با Cargo انجام می‌شوند باید بدون تغییر محسوس کار کنند، اما workflowای که فایل‌های .rlib را به‌صورت دستی link می‌کند ممکن است لازم باشد فایل .rmeta متناظر را نیز با --extern به کامپایلر بدهد. بنابراین cacheهای build یا wrapperهای اختصاصی کامپایلر که فرض می‌کنند همه فراداده داخل کتابخانه است، باید جداگانه آزمایش شوند.

نتیجه ایمن و عملی این است: فعلاً pipeline پایدار خود را بر اساس این رفتار بازطراحی نکنید. تیم Cargo می‌گوید پیش‌فرض nightly یک آزمایش برای جمع‌آوری بازخورد است و این قابلیت در حال حاضر برای پایدارشدن برنامه‌ریزی نشده است. کاربران nightly می‌توانند workspaceهای خود را آزمایش کنند، خطاهای مربوط به link دستی یا cache را زیر نظر بگیرند و regressions را گزارش دهند؛ کاربران stable بهتر است تا تصمیم آینده بر پایه این شواهد صبر کنند. این رفتار Cargo یک پیش‌فرض آزمایشی در nightly است، نه یک قابلیت پایدارشده؛ کاربران کانال stable تحت‌تأثیر آن نیستند.