هنگام کپیکردن فایلهای پروژه، رفتار خاصی از فایل اکسپلورر دیدهام: نوار پیشرفت با شتاب تا حدود ۹۰% جلو میرود، اما بعد همانجا گیر میکند و تا پایان کار بهکندی پیش میرود. هنگام کپیکردن یک فایل ویدیویی بسیار بزرگ چنین تجربهای ندارم و این تفاوت همیشه برایم وارونه و عجیب بوده است.
همیشه فرض میکردم این هم یکی از همان رفتارهای همیشگی ویندوز است. بااینحال، Robocopy، ابزار داخلی ویندوز، را در برابر فایل اکسپلورر آزمودم؛ سریعتر بود، اما نه دقیقاً آنطور که انتظار داشتم.
کپی 300MB بیشتر از 5GB طول کشید
تعداد فایلهای جداگانه نقشی تعیینکننده داشت

در رایانه من، فایل اکسپلورر برای کپیکردن حدود ۵,۰۰۰ فایل متنی با حجم کلی نزدیک به 300MB، تقریباً ۳۰ ثانیه زمان صرف کرد؛ یعنی سرعت میانگین حدود 10MB/s. بااینحال، روی همان درایو توانستم یک فایل 5GB را با سرعتی نزدیک به 260MB/s کپی کنم.
این تجربه شبیه تفاوت میان جابهجایی ۵,۰۰۰ پاکت و یک جعبه سنگین است. چیزی که حالت نخست را کندتر میکند، سربار رسیدگی جداگانه به هر مورد است. در رایانه، هر فایل باید مراحل بازشدن، نوشتهشدن، بستهشدن و ثبت اطلاعات را جداگانه پشت سر بگذارد. وقتی فایلها تا این اندازه کوچکاند، رسیدگی به تکتک آنها میتواند سهم چشمگیری از کل زمان کپی را به خود اختصاص دهد. فایل اکسپلورر پیش از آغاز کپی نیز حدود سه ثانیه مشغول «محاسبه» بود.
آزمایشی که با فایل اکسپلورر انجام دادم شامل ۵,۰۰۰ فایل متنی تولیدشده روی حافظه SSD مدل WD SN530 NVMe و ویندوز ۱۱ نسخه 25H2 (بیلد ۲۶۲۰۰.۹۴۵۷) بود. سپس Robocopy را برای همان پوشه اجرا کردم؛ ابزاری که از پیش در ویندوز وجود دارد.
ابزار داخلیای که هرگز بازش نکردهاید
Robocopy only beat File Explorer once I switched on one setting





ویندوز Robocopy، ابزار کپی خط فرمان، را بهصورت پیشفرض در اختیار شما میگذارد؛ بنابراین برای استفاده از آن لازم نیست چیزی نصب کنید. کافی است خط فرمان را باز و Robocopy را اجرا کنید. وقتی Robocopy را با /MT:1 وادار کردم فقط از یک رشته استفاده کند، تفاوت ناچیزی دیدم: کپی همان فایلها ۲۹ ثانیه طول کشید، درحالیکه فایل اکسپلورر این کار را در ۳۰ ثانیه انجام داده بود.
اما پردازش چندرشتهای همهچیز را تغییر میدهد. فرمانی که دقیقاً استفاده کردم این بود:
robocopy "C:\Source" "D:\Destination" /E /MT:16 /NFL /NDL /NP /LOG:C:\copy.log
/E به ابزار میگوید زیرپوشهها را نیز کپی کند و /MT:16 امکان کپی همزمان ۱۶ فایل را فراهم میکند. چهار گزینه پایانی، یعنی /NFL، /NDL، /NP و /LOG:C:\copy.log، نمایش زنده روند کار را غیرفعال میکنند و درنتیجه سربار نمایش اطلاعات در کنسول کاهش مییابد. البته برای دیدن آنچه رخ داده بود، باید پرونده گزارش را باز میکردم.
هنگام آزمایش، دو نکته مرا به اشتباه انداخت. مسیر مبدأ باید پیش از مقصد بیاید. وقتی عمداً جای آنها را عوض کردم، Robocopy مسیر دوم را مقصد در نظر گرفت و فایلها را در جهت مخالف کپی کرد؛ بیآنکه بپرسد آیا اشتباهی رخ داده است. همچنین محتوای پوشه مبدأ را مستقیماً در مقصد کپی میکند و پوشهای با نام Source درون آن نمیسازد.
فرمان من از ۱۶ رشته استفاده میکرد و زمان همان کپی را حدود یکچهارم کاهش داد؛ از ۳۰ ثانیه به ۲۲ ثانیه. صرفهجویی هشتثانیهای ناگهان روزتان را دگرگون نمیکند، اما کنجکاوم کرد. اگر ۱۶ رشته هشت ثانیه برایم صرفهجویی کرده بود، باید میفهمیدم ۱۲۸ رشته چه میکند.
عملکرد ۱۲۸ رشته تقریباً هماندازه ۴ رشته بود
پس از ۱۶ رشته، سرعت دیگر بهتر نشد؛ یک فایل بسیار بزرگ هم هیچ سودی نبرد

نتیجه کاملاً آن چیزی نبود که امید داشتم. وقتی فرمان را به /MT:128 تغییر دادم، عملیات ۲۵ ثانیه طول کشید؛ تقریباً همان نتیجهای که با /MT:4 به دست آورده بودم.
| تنظیم | زمان (ثانیه) | زمان صرفهجوییشده در مقایسه با فایل اکسپلورر |
|---|---|---|
| فایل اکسپلورر | 30 | مبنای سنجش |
| تنظیم /MT:۱ | 29 | حدود ۳% |
| تنظیم /MT:۴ | 25 | حدود ۱۷% |
| تنظیم /MT:۸ | 24 | به میزان ۲۰% |
| تنظیم /MT:۱۶ | 22 | حدود ۲۷% |
| /MT:۳۲ (۳۲ رشته) | 22 | حدود ۲۷٪ |
| /MT:۶۴ (۶۴ رشته) | 23 | حدود ۲۳٪ |
| /MT:۱۲۸ (۱۲۸ رشته) | 25 | حدود ۱۷٪ |
| /MT:۱ (اجرای دوبارهٔ آخرین آزمون) | 29 | حدود ۳٪ |
جدول بالا نتایج آزمایش من روی حدود ۵٬۰۰۰ فایل متنی تولیدشده، با حجم کلی نزدیک به ۳۰۰ مگابایت، را خلاصه میکند. همهٔ آزمایشها روی یک درایو NVMe SSD انجام شدند و پیش از هر بار اجرا، مقصد را پاک کردم. عدد ثبتشده میانهٔ سه بار اجراست.
تا ۱۶ رشته، افزایش کارایی پیوسته بود و پس از آن تقریباً ثابت ماند. از آنجا که اختلاف یکثانیهای در محدودهٔ نوسان طبیعی اجرای آزمایشهای من قرار میگیرد، نمیتوانم حالتهای ۱۶، ۳۲ و ۶۴ رشتهای را با اطمینان رتبهبندی کنم. برای اینکه مطمئن شوم گرمبودن حافظهٔ نهان فایلها نتایج بعدی را بهتر از واقع نشان نداده است، آزمایش File Explorer و /MT:1 را دوباره اجرا کردم. این بار نیز نتایج بهترتیب ۳۰ و ۲۹ ثانیه بودند.
نمیتوانم علت ثابتشدن کارایی را با قطعیت تعیین کنم. محتملترین حدس من این است که سرعت درایو، پویش آنتیویروس یا گلوگاه دیگری که برای هر فایل جداگانه رخ میدهد، به عامل محدودکننده تبدیل شده بود.
برای یک فایل ۵ گیگابایتی هیچ افزایش کاراییای دیده نشد. انتقال با File Explorer حدود ۱۹ ثانیه طول کشید و با /MT:1، /MT:16 و /J نیز همینقدر زمان برد؛ بنابراین هیچیک از این گزینهها این انتقال خاص را سریعتر نکردند. هنگام انتقال تنها یک فایل، /MT چند فایل در اختیار ندارد تا همزمان روی آنها کار کند؛ در نتیجه، رشتههای بیشتر نیز فرصتی برای بهبود کارایی نداشتند.
اگر روبوکپی را درست و برای گونهٔ مناسبی از فایلها به کار ببرم، همچنان انتخابم خواهد بود؛ اما باید یک نکته را در نظر داشت.
یک گزینهٔ کندکننده و فرمانی که فایلها را پاک میکند
تمام این آزمایش با یک درایو NVMe و فایلهای متنی تولیدشده انجام شد. بر پایهٔ این نتایج نمیتوان رفتار عکسها، دیسکهای سخت، حافظههای USB یا پوشههای اشتراکی شبکه را پیشبینی کرد.
چند گزینهٔ دیگر را هم آزمایش کردم:
| گزینه | کارکرد | نتیجه | نکتهٔ مهم |
|---|---|---|---|
/Z (حالت ازسرگرفتنی) |
حالت ازسرگرفتنی؛ در برابر وقفهها تاب میآورد | حدود ۲۵ ثانیه در برابر حدود ۲۲ ثانیه | حدود ۱۴٪ کندتر؛ اگر احتمال قطعشدن فرایند رونوشت وجود دارد، ارزش بررسی دارد |
/R:1 /W:1 (یک تلاش دوباره با یک ثانیه درنگ) |
یک بار تلاش دوباره، با یک ثانیه درنگ | هیچ فایل قفلشده یا ناموفقی وجود نداشت | پیشفرض، ۱٬۰۰۰٬۰۰۰ بار تلاش با فاصلهٔ ۳۰ ثانیه است؛ در نتیجه، از نظر نظری ممکن است عملیات برای مدتی بسیار طولانی متوقف بماند |
/MIR (آینهسازی) |
مقصد را آینهٔ مبدأ میکند و فایلهای اضافی مقصد را پاک میکند | فقط برای دادههای دورریختنی | ممکن است فایلها را پاک کند؛ نخست از /L استفاده کنید |
باید هنگام استفاده از /MIR بسیار مراقب باشید. این گزینه برای یکسانکردن مقصد با مبدأ، هر مورد اضافی را از مقصد پاک میکند. اگر مسیرها را جابهجا وارد کنید، ممکن است پوشهٔ اشتباهی را بهکلی پاک کنید.
تعداد پیشفرض تلاشهای دوباره ۱٬۰۰۰٬۰۰۰ بار (/R) است و میان هر تلاش نیز ۳۰ ثانیه (/W) درنگ میشود؛ به همین دلیل ممکن است چنین به نظر برسد که یک عملیات رونوشت مشخص برای همیشه گیر کرده است.
من بیشتر مایلم برای رونوشتبرداری از شمار زیادی فایل کوچک از روبوکپی استفاده کنم؛ اما دستاورد اصلی این آزمایش آن بود که فهمیدم افزایش شمار رشتهها سرانجام دیگر سودی ندارد و برخی گزینهها نیز میتوانند عملیات را کندتر کنند یا، اگر احتیاط نکنم، حتی فایلها را پاک کنند.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Afam Onyimadu است. مشاهده مقاله اصلی