Rust 1.98 مسیر قالببندی بافرمحور را برای اعداد صحیح فراهم میکند
Rust 1.98 متد `format_into` را پایدار کرده است؛ متدی که مقدارهای صحیح را در یک بافر عددی متعلق به فراخوان قرار میدهد. برای سرویسهای Rust و کانسترهای ICP که مرتباً شمارنده، شناسه یا مبلغ را سریالسازی میکنند، این API یک گزینه استاندارد برای مسیرهای قالببندی پرهزینه از نظر تخصیص حافظه است.
Rust 1.98.0 که در ۲۰ اوت منتشر شد، یک قابلیت کوچک اما کاربردی به کتابخانه استاندارد اضافه میکند: همه انواع صحیح داخلی اکنون متد format_into را در اختیار دارند.
این متد یک core::fmt::NumBuffer<Self> قابلتغییر میگیرد و یک برش رشتهای برمیگرداند که از همان بافر وام گرفته شده است. بافر شفاف نیست، اما Rust تضمین میکند که برای نمایش دهدهی هر مقدار از نوع صحیح مربوطه اندازه کافی دارد. این طراحی تصمیم مربوط به فضای ذخیرهسازی را صریح میکند: فراخوان فضای قالببندی قابلاستفاده مجدد را مالک است و طول عمر &str بازگشتی نیز به همان بافر وابسته میماند.
یک الگوی ساده چنین است:
let value: u64 = 42_000;
let mut buffer = core::fmt::NumBuffer::<u64>::new();
let text = value.format_into(&mut buffer);
assert_eq!(text, "42000");
تغییر اصلی، نحو جدیدی برای قالببندی نیست؛ بلکه ایجاد مرزی تازه میان تبدیل عدد و تخصیص حافظه است. اعلامیه انتشار Rust میگوید format_into بخش زیادی از dispatch پویا در قالببندی با write! بافرشده را کنار میگذارد و در بنچمارک پروژه میتواند عملکردی مشابه کتابخانه itoa داشته باشد. مخزن بنچمارک، کاری را شرح میدهد که شامل مقدارهای تصادفی u32، u64 و u128 است و آنها را بر اساس طول دهدهی گروهبندی میکند.
این قابلیت برای کدی اهمیت دارد که تعداد زیادی فیلد عددی کوتاه تولید میکند: خطوط تلهمتری، پیامهای پروتکل، شناسه حساب، شمارههای توالی و فراداده تراکنشهای سریالشده. یک بافر قابلاستفاده مجدد میتواند اشیای موقت را کاهش دهد و طول عمر متن قالببندیشده را در سیستم نوعها قابل مشاهده کند. در یک کانستر ICP یا سرویس Rust پشتیبان، این موضوع هنگام ساخت پاسخها یا لاگهای تکراری مفید است؛ هرچند خود API هزینه پیام یا قالب سریالسازی پیرامونی را حذف نمیکند.
پذیرندگان این API باید به دو نکته توجه کنند. نخست، format_into برای قالببندی دهدهی است و جایگزین عمومی برای قالببندی هگزادسیمال، دودویی، وابسته به locale یا سریالسازی ساختاریافته نیست. دوم، بنچمارک منتشرشده فقط یک مقایسه اندازهگیریشده را نشان میدهد، نه تضمین عملکردی همگانی: مخزن آن یک workload، ماشین و نسخه مشخص Rust را ثبت کرده است. بنابراین پیش از حذف یک وابستگی موجود، هر تیم باید مسیر پرتکرار واقعی خود را اندازهگیری کند.
مسیر مهاجرت عملی میتواند محافظهکارانه باشد: ابزار زنجیره را به Rust 1.98 ارتقا دهید، تبدیل محدود عدد به رشته را با format_into جایگزین کنید و تخصیص حافظه و تأخیر را در workload واقعی بسنجید. کدهای گستردهتر write! یا serializer را زمانی نگه دارید که قالب پیچیدهتری را بهتر بیان میکنند. در نتیجه Rust 1.98 یک بهینهسازی رایج را به گزینهای از کتابخانه استاندارد تبدیل میکند، بدون آنکه ادعا کند همه برنامهها باید به یک نتیجه عملکردی یکسان برسند.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.