قياس الأداء

النسخة المختصرة · قيست في 23 أغسطس 2026 على خط الكود الذي شُحن باسم nzbfast 1.2.2

لا عميل مقيس أرخص في المعالج والذاكرة والقرص معًا

أحدث الجولات في هذه الصفحة جرت في 23 و24 أغسطس 2026 - أحدثها على بناء الإصدار v1.2.2 نفسه - مقابل أحدث بُنى أربعة عملاء آخرين على عتاد وخطوط ومزوّدين متطابقين: شكلا مهمة من 6.5 إلى 87 GB، ومعدلات خط من 250 Mbit إلى 10 GbE. عبر تلك الجولات لم يكن أي عميل أرخص من nzbfast في المعالج والذاكرة والقرص معًا: كل واحد منها أغلى في اثنين من الثلاثة على الأقل، وأقصى ما وفّره أيّ منها على أي محور واحد كان نحو 2 بالمئة - تعادل إحصائي، ضمن تفاوت ذلك العميل نفسه بين التكرارات - وعلى القرص تحرّك كل واحد منها ضعف البايتات على الأقل مقابل نتيجة مطابقة بايت لبايت. وكما يُشحن، احتفظ nzbfast أيضًا بأقل ذاكرة بين كل عميل قِيس، على كل عيّنة، بمعدل 2.0 إلى 4.5 أضعاف مقابل أقرب منافس.

أيّ سطر يصفك؟

تكتب معظم برامج التنزيل تنزيلك إلى القرص مرتين على الأقل: مرة أثناء تنزيله، ومرة أخرى أثناء فك ضغطه. يؤدي nzbfast المهمة كاملة بمرور واحد، فيكتب نحو نصف البايتات لكل مهمة، ويحتفظ بأقل في الذاكرة أثناء العمل، وينفق ثوانيَ معالج أقل لكل جيجابايت. وهذا حِمل أقل على الجهاز أثناء استخدامك له، ونصف الكتابات لكل مهمة على أقراصك، لنفس الملفات المطابقة بايت لبايت - ولأن كل بايت يعبر القرص مرة واحدة تقريبًا، لا يحتاج قرصك مجاراة خطك إلا مرة واحدة.

لا يفوز nzbfast بكل جدول في هذه الصفحة، والجداول التي يخسرها موجودة تحت الأشواط التي لا نفوز بها - بما في ذلك واحد من الجولة نفسها. ما ثبت في كل جولة قِسناها هو الفاتورة الإجمالية.

المنهجية أولًا

الإعداد

• العملاء: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver، كل جدول بالبُنى التي يسمّيها. تسابقت أحدث الجولات (23 أغسطس 2026) مع البُنى الحالية حينها للميدان - SABnzbd 5.1.1، وNZBGet 26.3-testing، وrustnzb 1.4.5، وWeaver 0.7.8 بأحدث ثنائيّه المنشور، مثبتة هويته بالتجزئة (hash) - مقابل خط الشيفرة الذي شُحن تلك الليلة نفسها باسم nzbfast 1.2.2، فالبناء الذي أنتج الأرقام الجديدة هو ما يمكنك تنزيله. جرت تلك الجولات على جهاز Apple Silicon بعشرين نواة على خط 1 Gbit. أما الجداول الأقدم فتحتفظ بالبُنى والأجهزة التي سابقتها (أجهزة Apple من سلسلة M: "أوروبا" M1 Ultra على 10 GbE، و"الساحل الشرقي" M3 Ultra بخط ~2.4-3.0 Gbps) وتصرّح بذلك؛ وهي تُقلّل من شأن البناء المنشور بدل أن تُجمّله.
• العدالة: المزوّدون وTLS أنفسهم في كل مكان لكل عميل، والأشواط تجري متتابعة متداخلة. كل منافس ضُبط عند أفضل حاله الموثّق: حصل SABnzbd على pipelining_requests=8 (يُشحن بـ1، أي بلا أنابيب، والإعداد يستحق نسبًا مئوية مزدوجة الرقم على المهام الكبيرة)، وحصل NZBGet على ArticleCache وDirectWrite وDirectUnpack وParQuick، وحصل rustnzb على إعداده الموثّق. منذ 20 أغسطس 2026 تسابق كل جولة خمسة مزوّدين لا ستة - فعدد المزوّدين ليس رافعة سرعة على هذه الأجهزة، حيث يمكن لمزوّد واحد وحده بلوغ سقف الخط، ومجموعة ثابتة تُبقي الجولات قابلة للمقارنة - فرقم بستة مزوّدين في هذه الصفحة غير قابل للمقارنة المباشرة مع رقم أحدث بخمسة مزوّدين، وكل جدول يذكر أيّهما شغّل.
• الحالة النهائية: ملف متحقَّق منه، مستخرَج، قابل للاستخدام، لا مجرّد "انتهى التنزيل". هذا ما تنتظره فعليًا.
• القابلية للتكرار: كل ادعاء مؤرَّخ ومقيس بالطريقة نفسها: الزمن المنقضي + عدّادات بايتات الواجهة + ذروة RSS لشجرة العمليات، بدقة 1-2 s. وحيثما يجري شوط على NZB منشور علنًا، نسمّيه كي تُجريه بنفسك.
• ملاحظات منهجية تسري على الصفحة كلها: يُؤخذ زمن المعالج بالعيّنة من شجرة العمليات بتردد 2 Hz على كل ذراع من كل جدول ولا يُوضع أبدًا إلى جانب رقم من محاسبة مختلفة، لأن الطريقتين تختلفان بالتصميم. يُذكر إدخال/إخراج الجهاز بوحدة GiB وبايتات السلك بوحدة GB عشرية؛ ونحوّل قبل القسمة. وأي جدول يسابق بناءنا مقابل بنائنا نفسه يحمل ضابط A/A - الثنائي نفسه يسابق نسخة مطابقة بايت لبايت من نفسه عبر المنصة نفسها - لأن هذا الضابط هو كيف اكتشفنا أن منصة السباق لدينا كانت تمنح أيّ أداة تعمل أولًا عقوبة نحو 1.5% (القصة إلى جانب جداول الاستخراج أدناه). ذراعان وترتيب مبدَّل لا يُلغيان انحيازًا يقع دائمًا على الذراع الأول؛ ضابط A/A هو ما يكشفه.

الخطوط الأبطأ · قيست في 24 أغسطس 2026 على nzbfast 1.2.2

كلما أبطأ الخط قلّ ما يفرّق بين العملاء في السرعة، وزاد ما تفرّقه الفاتورة

على خط بطيء بما يكفي، يصير زمن إنهاء كل عميل هو السلك ولا شيء غيره، فالخط البطيء يخفي كثيرًا من الخطايا. ما لا يستطيع إخفاءه هو ما يحرقه كل عميل ليملأه. شكّلنا منصة الـ1 Gbit عند معدلين حقيقيين تكون عليهما خطط فعلية وسابقنا الأذرع الستة عند كل واحد منهما - الجهاز نفسه، والمزوّدون الخمسة أنفسهم، ثلاث تكرارات لكل عميل مع تدوير الترتيب، وتحقق من كل شوط بايت لبايت، 36 من 36 صحيحًا عبر الجولتين. ذراع nzbfast عند 500 Mbit هو بناء إصدار v1.2.2 نفسه.

اقرأ الجدولين كتدرّج. عند 250 Mbit يقع الميدان كله ضمن 18% على الساعة ونتصدّر على أقرب منافس بـ4.4%؛ عند 500 Mbit تتّسع الفجوة إلى 14.7%؛ وعند معدلَي الجيجابت و10 GbE في الجدولين أعلاه وأدناه تتّسع أكثر. فروق السرعة تكبر مع الخط. أعمدة الموارد لا تنتظر خطًا سريعًا: عند كل معدل مقيس، احتفظ كل منافس بـ3.9 أضعاف الذاكرة على الأقل، وأنفق معالجًا أكثر، وحرّك نحو ضعف بايتات القرص لنفس الملف المطابق بايت لبايت.

يكسب منظّم الاتصالات ثمنه على الخطوط البطيئة، وعدّاد الإسقاط الخاص بالمشكِّل يقول لماذا. أبقت الإعدادات الافتراضية للشحن 25 اتصالًا حيث شغّل كل منافس مئات؛ والثنائي نفسه مع إيقاف المنظّم شغّل 360. تدفّقات أقل عبر طابور ثابت تعني فقدانًا أقل وإعادة إرسال أقل: سجّل المشكِّل نحو 4,200 إسقاط لكل شوط مسقوف مقابل نحو 155,000 غير مسقوف عند 500 Mbit، وكان الذراع المسقوف أسرع، وأخفّ بـ4.2 أضعاف على الذاكرة، وأخفّ بـ1.3 ضعف على المعالج من وضعية الـ360 مقبسًا الخاصة بنا. مزيد من الاتصالات ليس مزيدًا من السرعة؛ دون الجيجابت هو العكس قياسًا.

قيست في 24 أغسطس 2026، أوساط ثلاث تكرارات، على جهاز Apple Silicon بعشرين نواة مع تشكيل خطه عند كل معدل (المعدل المشكَّل تحقّق منه مسبار مستقل قبل كل جولة: 248 و496 Mbit). ذراع nzbfast عند 500 Mbit هو بناء وسم الإصدار v1.2.2؛ وجرت جولة 250 Mbit قبل ساعات على خط الشيفرة نفسه. تُقرأ أعداد البايتات على خط مشكَّل من عدّاد كل عميل الخاص، لا من واجهة الشبكة أبدًا (يُسقط المشكِّل ويعيد TCP الإرسال، فتحسب الواجهة النسختين معًا). الساعات قابلة للمقارنة داخل كل جدول، لا عبر جولات مشكَّلة مختلفة. ¹ امتدت أشواط NZBGet الثلاثة عند 500 Mbit من 114 إلى 158 s بقراءات موارد ثابتة - تفاوت حقيقي، فيُذكر الوسيط ويُذكر التفاوت بدل تضييقه.

المنشور التالف · أُعيد السباق في 24 أغسطس 2026، كل بناء حالي

حين يكون المنشور مثقوبًا: 6.5 GB بـ60 و20 و5 مقالات ميتة

تنتهي صلاحية المقالات، وتُسقطها الخوادم بصمت، وتصل الرفعات ناقصة - والتلف هو حيث تكون الفجوة بين العملاء أوسع ما تكون، فله جولته الخاصة على أحدث بناء لكل عميل، بما فيه nzbfast v1.2.2: جهاز أوروبا 10 GbE، وخمسة مزوّدين، و100 اتصال لكل عميل، الإصدار نفسه بحجم 6.5 GB مسمَّم عند ثلاثة مستويات تلف، ثلاث تكرارات لكل ذراع مع تناوب الترتيب، وتحقق من كل شوط بايت لبايت مقابل الملف النظيف. عادت 63 من 65 شوطًا مطابقة بايت لبايت؛ والشوطان اللذان لم يعودا كذلك مسمّيان أدناه، لأنهما نتيجتان.

لماذا المنشور التالف سريع هنا. حين تُفقَد مقالة، يسأل العميل عادةً الخادم التالي، ثم الذي يليه، حتى يرفضها كل خادم - سير متسلسل يستغرق فيه كل رفض بين عشرات المللي ثانية وثانيتين، يقعد التنزيل خلاله عند الصفر. يتوقّف nzbfast عن السؤال: بمجرد أن تغطي بيانات التكافؤ الموجودة أصلًا ما زال مفقودًا، يُصلح فورًا بدل إنهاء السير. هذا هو الصف الثاني - الثنائي نفسه بإيقاف ذلك السلوك أبطأ بـ1.4 إلى 2.3 أضعاف حسب التلف - وتحققت الجولة من أن الآلية عملت في كل شوط مفعَّل ولم تعمل أبدًا في شوط معطَّل. مقابل أقرب منافس الهامش من 2.4 إلى 2.7 أضعاف، بلا تداخل في أيّ من أزواج التكرار التسعة.

القرص هو حيث الهامش أوسع ما يكون، وليس هذا حيلة الإصلاح. أنتج كل ذراع مكتمل الملف نفسه بحجم 6.48 GB؛ حرّكنا 6.2-6.8 GB من إدخال/إخراج القرص لفعل ذلك، وNZBGet 12.7-18.5 GB، وSABnzbd 13.9-20.3 GB، وrustnzb 12.8-13.1 GB. هذا هو خط أنابيب المرور الواحد - يحرّك الصف المُوقَف نفس الـ6.2 GB - فهو يصمد على المنشورات التالفة وغير التالفة سواء بسواء.

¹ جرت أشواط SABnzbd الثلاثة عند أثقل تلف في 43 و41 و60 s - تفاوت حقيقي على مدخلات متطابقة، فيُذكر المتوسط مع ذكر المدى. ² سلَّم rustnzb 1.4.5 كل شوط صحيحًا بايت لبايت، وتكلفته في زمن المعالج لا في الموثوقية: نحو 1,620 ثانية معالج مقابل ساعة 107 s عند أثقل تلف - نحو خمسة عشر نواة مشغولة طوال الشوط - حيث يكلّفنا الناتج المُصلَح نفسه نحو 50 ثانية معالج. ³ حرّك Weaver 1.5 GB و4.9 GB من الـ6.5 ضمن مهلتنا البالغة 20 دقيقة عند مستويَي التلف الأثقل - عدم الإنهاء نفسه في الجولات الثلاث التي سابقته، في ثلاث ليالٍ منفصلة؛ المهلة لنا وعدم الإنهاء هو النتيجة. عند 5 مقالات ميتة أكمل صحيحًا في المرّات الثلاث. تكلفة معالجه هناك قصتها الخاصة: نحو 2,325 ثانية معالج للشوط البالغ 194 s، مقابل 20 لدينا.

قيست في 24 أغسطس 2026، كل بناء حالي: nzbfast v1.2.2 (وسم الإصدار نفسه)، وNZBGet 26.3-testing (بناء 20 أغسطس)، وSABnzbd 5.1.1، وrustnzb 1.4.5، وWeaver 0.7.8. سابق ذراع استمرارية بناء nzbfast الخاص بالليلة السابقة داخل هذه الجولة نفسها ووقع في ثانية واحدة من v1.2.2 على كل عيّنة، فلا شيء هنا يعتمد على ليلة محظوظة؛ وإعدادات المنافسين لا تختلف عن الجولة السابقة إلا في مسار التطبيق، مُتحقَّق منها إعدادًا إعدادًا قبل تشغيل الجولة.

تجويعه من RAM · قيست في 24 أغسطس 2026 على nzbfast 1.2.2

سلّم الذاكرة المنخفضة: 87 GB في ~0.3 GB من RAM

المهمة نفسها بحجم 87 GB من الجولة أعلاه، أُعيد تشغيلها بميزانيات ذاكرة صارمة عند 2 GB و1 GB و256 MB - ما قد يختاره المُحجِّم التلقائي على جهاز 8 GB، وجهاز 4 GB، وNAS بحجم 2 GB. أنتج كل شوط الملف نفسه المُتحقَّق منه بايت لبايت، وتتبّع عمود الذاكرة الميزانية، لا المهمة أبدًا:

شوط واحد لكل ميزانية على بناء الإصدار، محكوم مقابل المجموع التحققي نفسه للناتج في الجولة السداسية الأذرع. تكلّف أضيق ميزانية نحو 9% من الساعة، وذلك فقط لأن هذا الخط هو 10 GbE - لا تكلّف الكتل المُسكَبة إلى القرص وقتًا إلا حين يتخطّى الخط القرص سرعةً، فعلى اتصال منزلي نموذجي تكاد ميزانية صغيرة أن تكون مجانية. يتّسع السلّم كله، بما فيه تنزيل بحجم 87 GB، في 0.3-0.6 GB من الذاكرة؛ وبالإعدادات الافتراضية للشحن جرت المهمة في 286 MB. لا يعرض أي عميل آخر ميزانية ذاكرة صارمة على مستوى العملية كله؛ أقرب ما لديهم مفاتيح حجم ذاكرة تخزين مؤقت، والجولة أدناه تقيس ما تكلّفه تلك المفاتيح.

القيد سابَق مقابل مفاتيح الميدان نفسها. على عيّنة الـ34 GB (23 أغسطس 2026، جهاز 1 Gbit، خمسة مزوّدين، 30 من 30 شوطًا صحيحًا بايت لبايت)، أدّى تقييد NZBGet بذاكرة تخزين مؤقت معادلة إلى أكثر من مضاعفة معالجه (من 215.5 إلى 453.0 ثانية معالج، أي 2.10x) لشراء تخفيض 52% في ذروة ذاكرته، وكان قيد SABnzbd شبه مجاني لكنه بلغ جزءًا فقط من بصمته. كان إعداد ذاكرة rustnzb التخزينية زخرفيًا في البناء المسابَق، ولا يملك Weaver أي مفتاح ذاكرة على الإطلاق، فعملا كلاهما بلا قيد كعمودين مرجعيين بدل أن يُقيَّما عند ميزانية لا يستطيعان الالتزام بها. جانبنا من تلك الجولة يتخطّاه سلّم v1.2.2 أعلاه، الذي يقول الشيء نفسه بـ2.5 أضعاف الحجم: الميزانية ليست أبدًا القيد المُلزِم، لأن المرور الواحد يحتفظ بقليل جدًا من الأساس.

المساحة الحرة · قيست إلى الميغابايت

كم من المساحة الحرة تحتاجها المهمة

يحتاج عميل يكتب ثم يفك الضغط إلى مكان لمجلدات الأرشيف والحمولة المفكوكة في آن واحد، فلن تبدأ المهمة دون نحو ضعف مساحة التنزيل حرّة. يحتاج المرور الواحد الحمولة - وقاست هذه الجولة كم أكثر بالضبط، بتصغير مجلد الهدف حتى يفشل كل عميل. إجابة nzbfast هي ثابت قدره نحو 50 MB من الهامش، لا نسبة، ويصمد من مهمة بحجم 6.5 GB إلى أخرى بحجم 34 GB.

قيست على جهاز Apple Silicon بعشرين نواة، وخط 1 Gbit، وخمسة مزوّدين، وثلاث تكرارات عند كل حد، وتحقق من كل شوط مكتمل بايت لبايت - صفوف المنافسين في 22-23 أغسطس 2026 (أُعيد تشغيل خلية Weaver البالغة 34 GB في 24 أغسطس، الحاشية 1)، وصف nzbfast أُعيد قصّه على بناء إصدار v1.2.2 في 24 أغسطس، وأعاد إنتاج الحدّين تمامًا، بإجماع 12 من 12 شوطًا عبر العيّنتين. خلايانا هي حد أدنى مقيس: تكتمل المهمة 3 من 3 بهامش 48.6 MB و51.0 MB، وتُرفض 3 من 3 عند نحو 17 MB دون ذلك - فالحد الأدنى حقيقي في الاتجاهين. ما تحتفظ به المهمة فعليًا يستقر عند الناتج زائد نحو 3 MB؛ يدفع الهامش ثمن اللحظات الأخيرة من خط الأنابيب، لا لنسخة ثانية أبدًا. خلايا المنافسين هي حدّها الأدنى المقيس على مهمة الـ6.5 GB وكفاية مؤكَّدة عند النسبة نفسها على مهمة الـ34 GB (3 من 3 صحيحة بايت لبايت عند تلك النسبة بالضبط)؛ لم نمشِ بسلّمهم أبعد عند الحجم الأكبر، فقد يقع حدّهم الأدنى الحقيقي هناك تحت النسبة إلى حدّ ما، ونقول ذلك بدل التقريب لصالحنا.

ما يبدو عليه النفاد فعليًا يهمّ بقدر الرقم نفسه. عند 17 MB دون حدّه الأدنى يصطدم nzbfast برفض القرص عند الكتابة، ويتوقّف بنظافة برسالة "نفدت مساحة القرص"، ويحتفظ بكل ما وصل مُسجَّلًا في اليوميات، وتستأنف إعادة المحاولة دون إعادة الجلب - جزء تحتفظ به، لا مهمة فاشلة. ¹ حُسم عمود Weaver على العيّنة الكبيرة بإعادة تشغيل في 24 أغسطس: ثلاثة أشواط من ثلاثة صحيحة بايت لبايت عند النسبة ~2.25x نفسها، كل منها أسرع من الشوط الجيد في المحاولة الأولى، بمساحة حرة متطابقة حتى البايت. في المحاولة الأولى، في 23 أغسطس، كان اثنان من أشواطه الثلاثة قد تعطّلا عند سرعات أحادية الرقم بالميغابايت في الثانية مع أكثر من 60 GB ما زالت حرّة وبلغا مهلة الجولة البالغة 40 دقيقة. لم تتكرر تلك التعطّلات، وكانت أدوات قياس التعطّل في المنصة منشورة وصامتة في الأشواط الثلاثة لإعادة التشغيل، وهذه قراءة إيجابية لا قراءة غائبة. ما سببها ما زال مجهولًا، وإعادة تشغيل نظيفة ليست تشخيصًا: توجد الآن ستة أشواط عند هذه النسبة، اكتمل أربعة منها، والإخفاقان كلاهما من نافذة واحدة مدتها 80 دقيقة في الليلة الأولى.

منشورات متداخلة · قيست في 28 أغسطس 2026

عشر طرق لتغليف منشور، ومن يصل فعلاً إلى الملف

كثير مما يُنشر صعب الفتح عن قصد. اسم الملف الحقيقي مدفون داخل أرشيف ثانٍ، وأحياناً ثالث، وأحياناً بصيغة مختلفة في كل طبقة، حتى يكشف المنشور أقل ما يمكن عما يحتويه. يضاف إلى ذلك أن المنشورات تصل تالفة: تنتهي صلاحية المقالات، وتصل الرفعات ناقصة، ويجب استخدام بيانات الاسترجاع قبل أن يمكن استخراج أي شيء. إما أن يسير برنامج التنزيل في تلك السلسلة نيابةً عنك، أو يسلّمك مجلداً مليئاً بالأرشيفات ويتوقف.

لذلك بنينا عشر صيغ تعزل هذا الأمر بالضبط، وواجهنا بها كل برنامج حالي، ثم فعلنا ما تتخطاه المقارنات عادةً: حيث توقف برنامج مبكراً، أكملنا العمل يدوياً بالأدوات المعتادة وقِسنا زمن ذلك أيضاً. البرنامج الذي يستسلم بسرعة يبدو سريعاً حتى تحسب العمل الذي تركه لك.

nzbfast هو الوحيد الذي ينهي العشر جميعها دون مساعدة. يصل NZBGet إلى الملف في كل صيغة أيضاً، لكنه يحتاج إلى 16 جولة من الإصلاح والاستخراج اليدويين في ثمانٍ منها. ينهي SABnzbd خمساً بمفرده، وتبقى اثنتان بعيدتي المنال حتى يدوياً. يصل Weaver إلى الملف في اثنتين.

النمط ليس عشوائياً. الصيغ التي يجتازها nzbfast ولا يجتازها غيره هي المغلّفة والتالفة: أرشيف داخل أرشيف، وتغيير للصيغة في منتصف السلسلة، وسلسلة من خمس طبقات، وقبل كل شيء أرشيف يصل تالفاً ومعه بيانات الاسترجاع الخاصة به. في هذه الأخيرة تستخرج أربعة برامج المجموعة الخارجية استخراجاً سليماً، وتسلّمك الأرشيف المعطوب مع مجموعة الاسترجاع التي كانت ستصلحه، ثم تتوقف.

حيث تنجز البرامج العمل نفسه، الفارق ليس ضئيلاً. هذه هي الصيغ السبع التي تصل إليها البرامج الأربعة الشائعة جميعها، محتسباً الإصلاح اليدوي الذي احتاجه كل منها:

أسرع بأربع إلى خمس مرات، وبأقل من نصف البايتات المكتوبة. رقم القرص هو الذي يظل مهماً بعد التنزيل: كل جيجابايت في ذلك العمود جيجابايت اضطر قرصك إلى استيعابه، والبرامج التي تستخدم منطقة وسيطة تكتب المحتوى ثم تعيد قراءته ثم تكتبه مرة أخرى.

حيث لا نتقدم، ولماذا يستحق ذلك القول. في أربع من الصيغ العشر يكتب منافس بايتات أقل من nzbfast أثناء التنزيل نفسه. في كل مرة لأنه أنجز أقل: في صيغة الأرشيف الداخلي التالف يكتب NZBGet 3.29 GB مقابل 4.65 لدينا، ثم تكتب جولة الإصلاح لديه 2.91 إضافية لينتهي عند 6.20 GB مقابل 4.65 لدينا. في البقية، البرنامج الذي كتب أقل قدر هو برنامج لم يصل إلى الملف إطلاقاً. الرقم الصغير على القرص ليس اقتصاداً دائماً.

هذه اختبارات قدرة، لا اختبارات سرعة. المحتويات صغيرة وتُقدَّم من الذاكرة عبر اتصال محلي، بلا مزود وبلا شبكة في المسار، فلا شيء هنا مقيَّد بسرعة التنزيل، والثواني المطلقة أقصر بكثير مما ستستغرقه الصيغ نفسها في الواقع. أما إن كانت الصيغة تتطلب عملاً يدوياً أصلاً فتلك خاصية للصيغة وللبرنامج وتنتقل مباشرة. الثواني تقارن برامج تؤدي عملاً متطابقاً؛ وهي لا تتنبأ بمدة مهمة حقيقية.

النتائج الكاملة لكل صيغة، وماهية كل صيغة، والمنهج موجودة في صفحة بيانات الأرشيفات المتداخلة.

لماذا يهمّ

قرصك يتحمّل نصف العمل

يبلى التخزين الفلاشي بالكتابة إليه. يكلّف إصدار بحجم 94 GB قرصك نحو 90 GB من الكتابة تحت nzbfast؛ وتحت عميل يُدرِّج ويفك الضغط، يكلّف الإصدار نفسه نحو الضعف. على NAS بأقراص صلبة يزيل شكل المرور الواحد أيضًا المرور الطويل أحادي الخيط في نهاية كل تنزيل مشفَّر - وقفة قيست بـ20 ثانية على محطة عمل بـ32 نواة سريعة بفك قفل مسرَّع بالعتاد، وأطول تناسبيًا على الأجهزة منخفضة الطاقة التي يشغّل عليها معظم الناس هذا فعليًا. نذكر الرقم الصغير لأنه ما قسناه.

مبارزات المكوّنات

القياسات الأكثر تقنية، لمن يحب مزيدًا من البيانات

الإصلاح (PAR2) وفك الضغط (RAR) هما شيفرتنا الأصلية لا ثنائيات خارجية مرفَقة، فنسابقهما أيضًا مستقلَّين مقابل الأدوات المخصَّصة على عيّنات متطابقة، على أربعة أجهزة تمتد مما قد يملكه القارئ فعليًا. لا يُحتسَب زمن إلا حين يكون الناتج مطابقًا بايت لبايت لحمولة المصدر: كل رقم RAR أدناه تحقّقنا منه بـsha256 مقابل المصدر، وكل ملف مُصلَح مقابل المجموعة السليمة.

استخراج RAR: 7 أشكال أرشيف، 6 أدوات

استخدمت الجولة السابقة من هذا الجدول من 100 MB إلى 200 MB لكل شكل، وكان ذلك خطأ: كان نحو 28 ms من إطلاق العملية يمثّل 40% من شوط التخزين، والترتيب الذي أنتجه لا يصمد بحجم واقعي. هذه الجولة 1 GB من الحمولة لكل شكل، وهي تغيّر عدة إجابات، بعضها في الاتجاه الآخر. أُنشئت الأرشيفات بأداة rar الرسمية 7.23، فلا تُحكَم أي أداة على مدخل من مُرمِّزها الخاص، وتُسابق البايتات نفسها على كل جهاز.

ما في الحمولة يهمّ أكثر مما يبدو. حمولة مبنية من نسخ كتل تجعل كل شكل مضغوط قياس نسخ ذاكرة؛ وحمولة نص صرف تجعله قياس حروف وHuffman؛ قسنا كلا الأمرين ولا يتّفقان على الفائز. فالأشكال المضغوطة الأربعة تستخدم أثلاثًا متساوية من النص والسجلات المهيكلة والبايتات غير القابلة للضغط، والشكلان عند طرفَي ذلك المدى ذراعان منفصلان عمدًا: store غير قابل للضغط وrepetitive كله تقريبًا تطابقات. باني العيّنة والمنصة موجودان في المستودع، فيمكن إعادة بناء العيّنة بايتًا لبايت.

أُعيد السباق في 23 أغسطس 2026 على محرّك 1.2.2، والمسح يصمد. الأدوات الثلاث التي يزنها القارئ أكثر ما يزن - أداتنا، وunrar 7.23، وrarpar 0.2.5 - أُعيد سباقها على المكتب ذي الـ32 نواة على محرّك الإصدار (شيفرة الاستخراج المسابَقة مطابقة بايت لبايت لوسم 1.2.2)، ست جولات متداخلة، الأدنى لكل أداة، وناتج كل شوط مُتحقَّق منه مقابل بيان العيّنة. ثوانٍ، الأقل أفضل:

كل الأشكال السبعة لنا، على الأدنى وعلى الوسيط، من 1.16x إلى 4.29x مقابل unrar. هذه الأزمنة غير قابلة للمقارنة خليةً بخلية مع الجدول الأوسع أدناه - نُقِّحت المنصة منذ جولات ذلك الجدول وتختلف أعداد الجولات - فاقرأ كل جدول مقابل نفسه. يحتفظ الجدول الأوسع بتواريخه الخاصة وميدانه السداسي الأدوات، ويصف عمود nzbfast فيه المحرّك الذي يشحنه 1.2.2: قاست إعادة السباق أعلاه المحرّك الحالي مستوًى مع بناء ذلك الجدول على الأشكال السبعة كلها، محسومًا بعدد تعليمات العتاد (0.14% أقل للساعة نفسها)، فتلك الخلايا ليست أرقام بناء متجاوَز يرتدي تسمية حالية. وإعادة السباق هذه هي أيضًا حيث كُسبت قاعدة A/A في قسم الإعداد. أبلغ تمرير في اليوم نفسه أولًا عن شكل واحد كتراجع طفيف مقابل بنائنا السابق، وصمدت القراءة عبر تشغيل كلا ترتيبَي الأذرع. أظهر ضابط A/A - الثنائي نفسه يسابق نسخة مطابقة بايت لبايت من نفسه - أن المنصة كانت تمنح أيّ ذراع يعمل أولًا عقوبة نحو 1.5%: فاز الثنائي نفسه بـ6 من 15 جولة فقط من الفتحة الأولى، وتبديل الترتيب لا يُلغي انحيازًا يقع دائمًا على من يعمل أولًا. حسم عدد تعليمات العتاد السؤال الذي عجزت المنصة عن حسمه - يقاعد البناء الأحدث 0.14% تعليمات أقل للساعة نفسها، فلا تراجع هناك. كل مقارنة بناء مقابل بنائنا ننشرها الآن تحمل ذلك الضابط.

الميدان كله، ثوانٍ، الأقل أفضل. أفضل ثلاث، الأدوات متداخلة داخل كل جولة لا مشغَّلة في كتل، والناتج مُتحقَّق منه مقابل حمولة المصدر في كل تشغيل واحد. أداة أنتجت بايتات خاطئة تحصل على ملاحظة صحة، لا زمنًا سريعًا أبدًا. rarpar هي شيفرة RAR وPAR2 الخاصة بـWeaver، مبنيّة من المصدر عند bd87611؛ نثبّت الالتزام (commit) لا الإصدار لأن حزماته تحمل ثلاثة أرقام إصدار مختلفة.

حيث عجز الميدان عن المنافسة، ولماذا. ¹ إن 7-Zip المُسابَقة هنا هي حزمة Homebrew، التي ترفض كل شكل مضغوط برسالة ERROR: Unsupported Method ولا تقرأ إلا الشكل المخزَّن على macOS. نسبت نسخة أقدم من هذه الصفحة ذلك إلى بناء 7-Zip لـmacOS، وكان ذلك خطأ: يبنيها Homebrew دون مرمّز unRAR غير الحر، بينما يحمل بناء macOS الذي يشحنه 7-zip.org المرمّز ويفكّ الأشكال السبعة كلها، كما يفعل بناء Windows. أُعيد القياس في 14 أغسطس 2026. إن ثبّتّ 7-Zip من المشروع لا من Homebrew، فهذا العمود لا يصف ما لديك. ² لا يدعم bsdtar تعدد مجلدات RAR5 وأنتج ملفًا مبتورًا دون الإبلاغ عن خطأ، فذلك الشوط فشل صحة لا زمنًا بطيئًا؛ اكتشفته منصتنا بفحص الناتج، وهذا سبب قيمة فحص الناتج. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ لا يشحن unar أي أداة سطر أوامر لـWindows، فميدان المحمول خمسة. ⁶ تسابق مجموعة M5 Max الأدوات الثلاث التي قد يقصدها قارئ macOS فعليًا - unrar وrarpar ونحن؛ لم تُسابَق unar وbsdtar وZip-7 على ذلك الجهاز. نسخة unrar عليه هي 7.22، أحدث بناء يعمل دون تدخّل هناك.

كل شكل على كل جهاز إلا واحدًا، وذلك الواحد تعادل. ترجع أشكال التطابقات القصيرة إلى شيئين محدَّدين في مفكِّكنا. كانت مطابقة من اثنين إلى اثنين وثلاثين بايتًا تدفع ثمن استدعاء كامل لروتين نسخ الذاكرة في المنصة، وكان الاستدعاء يكلّف أكثر من النسخ؛ نسخ اثنين وثلاثين بايتًا ثابتة عبر سجلّ بدلًا من ذلك هو سبب سرعة repetitive وsolid وقاموس 128 MiB - الأشكال الثلاثة المبنية من تطابقات قصيرة - جميعًا دفعة واحدة. ويعمل المجموع التحققي في مسار منفصل عن خيط الكاتب لا عليه. الخلية الوحيدة التي لا نفوز بها صراحةً هي الشكل المخزَّن على المكتب ذي الـ32 نواة، حيث نبعد نحن وunrar ثلاث مللي ثانية على شوط ينقل بايتات صرفة - متطابقان عند دقة هذا الجدول، فتُوسَم الخليتان معًا ويُحتسب تعادلًا، لا خسارة ولا فوزًا.

الشكل الذي نفوز به بأكبر فارق هو ما يُنشر منه يوزنت فعليًا مئات في المرة: 400 ملف صغير، 4.3× و4.4× مقابل unrar و5.4× إلى 5.5× مقابل rarpar. تلك موازاة على مستوى العضو، وهي الفرق بين مستخرِج كُتب لطابور تنزيل وآخر كُتب لسطر أوامر. الشكل المخزَّن، الذي يقول الإحصاء أعلاه إنه 84% من البايتات على السلك، شبه تعادل بين الأدوات الجادة الثلاث، لأن الجميع عند تلك النقطة ينقل بايتات فحسب.

خيار يستحق التصريح به. تُحزَم الأرشيفات بضغط مثبَّت عند أربعة خيوط. يتبع تقسيم كتل RAR خلاف ذلك عدد أنوية أي جهاز حزم الأرشيف، فينتج مكتب بـ32 نواة ومكتب بـ20 نواة بايتات مختلفة من المدخل نفسه وتتوقّف الأجهزة عن كونها قابلة للمقارنة. تثبيته يجعل عيّنة الاستخراج مطابقة بايت لبايت في كل مكان، وهذا هو المقصود، لكنه أيضًا يسقف مقدار ما يمكن لفكّ الضغط تشغيله بالتوازي - فحين كان أقرب شكلين خسارتين أعدنا سباقهما مقابل أرشيفات حُزمت بكل الأنوية الـ32، للتحقق من أن التثبيت لم يكن السبب. لم يكن كذلك: تحرّك solid من 4.2% متأخرًا إلى 2.4% متأخرًا، وقاموس 128 MiB من 6.6% إلى 6.3%، الترتيب نفسه في الحالتين. كلاهما فوزان الآن على العيّنة المثبَّتة بفارق أوسع مما يمكن لذلك الفحص تفسيره.

لماذا لا صف لـRAR4، وماذا يحدث لتلك المنشورات. كل شكل أعلاه هو RAR5 أو RAR7، وهو ما ينشره يوزنت اليوم. لا تزال أرشيفات RAR4 الأقدم تظهر، ويقرأها المحرّك نفسه، بما فيها الأشكال المضغوطة والمحمية بكلمة سر، بالمرور الواحد نفسه بدل كتابة المجلدات إلى القرص وفكّ ضغطها لاحقًا. لا صف لها هنا لأن أداة rar الرسمية 7.23 لم تعد تستطيع إنشاء RAR4، فلا عيّنة محايدة لسباق الميدان عليها؛ ذلك العمل مُتحقَّق منه مقابل أرشيفات كتبها WinRAR 3.00 بدلًا من ذلك، بايتًا بايت مقابل unrar.

تحقق وإصلاح PAR2: مجموعة 1 GiB، أربعة مستويات تلف

العيّنة: 1 GiB من حمولة عشوائية حُزمت بنمط التخزين في 21 مجلد RAR، ثم مجموعتا PAR2 عند 10% تكرار، واحدة بكتل 1 MiB وأخرى بكتل 64 KiB، ثم خرائط تلف ثابتة. يستخدم كل تشغيل البروتوكول نفسه: نسخة طازجة، اقرأ العيّنة كاملة مرة لتدفئة ذاكرة التخزين المؤقت، ثم اقِس. أفضل ثلاث جولات متداخلة؛ يُقارَن كل مجلد مُصلَح مقابل المجموعة السليمة في كل جولة. الأقل أفضل.

تصحيح بشأن العيّنة، لأن نسخة أقدم من هذه الصفحة بالغت فيه. قلنا إن كل جهاز شغّل عيّنة مطابقة بايت لبايت، مُتحقَّقًا منها بالتجزئة. تجزئة كل مجلد في كل مجموعة تُظهر أن ذلك صحيح على المكتب ذي الـ32 نواة والمحمول Windows، وهما متطابقان تمامًا، وليس صحيحًا على المكتب ذي الـ20 نواة، الذي يحمل سحبًا عشوائيًا مختلفًا من الشكل نفسه: المجلدات الـ21 نفسها بالأحجام نفسها، وحجما الكتلة نفسهما، والتلف مُتحقَّقًا منه عند 3 و101 و1,500 كتلة نفسها موزّعة عبر عدد الملفات نفسه. كل رقم داخل صف واحد ما زال مقيسًا على بايتات تشتركها كل أداة في ذلك الصف، وهو ما ترتكز عليه كل مقارنة. لكن الصفوف ليست أربع نظرات إلى مدخل واحد، وبما أن طابع الحمولة يستحق نحو 7% لأحد المنافسين في مسحه، فذلك يستحق ذكره بدل التعتيم عليه.

أيّ par2 هو أيّ. par2cmdline الأصلي هو التطبيق المرجعي الذي تفرَّع منه الجميع. par2cmdline-turbo هو التفرّع الذي يزوّد نوى Galois-field المكتوبة يدويًا بـSIMD من ParPar: هذا بالضبط ما تعنيه كلمة "turbo"، وهذا سبب استحقاق turbo، لا الأصلي، القياس مقابله. يشغّل عمودا turbo أدناه نوى ParPar نفسها. ما يفرّقهما ليس الحساب بل البناء والخيارات.

تأكَّد على البناء المشحون مقابل المنافس الحالي، في 24 أغسطس 2026. قيست هذه الجداول قبل قصّ 1.2.2 وقبل أن يُصدِر par2cmdline-turbo النسخة 1.5.0 (20 أغسطس 2026)، فأُعيد سباق عمود العشرين نواة على كليهما: بناء إصدارنا 1.2.2 مقابل turbo 1.5.0، ثلاث جولات متداخلة لكل شوط، وكل ملف مُصلَح مقارَن مقابل المجموعة السليمة. تعيد كل الأشواط الأربعة إنتاج النتيجة - أرقامنا 0.18 / 0.30 / 0.75 / 2.02 مقابل 0.19 / 0.33 / 0.74 / 2.07 المطبوعة هنا، ويهبط turbo 1.5.0 ضمن نسب مئوية قليلة من بناء الجدول على كل شوط وكلا الإعدادين. تبقى الخلايا كما نُشرت؛ وتحتفظ الأجهزة الثلاثة الأخرى بتواريخها الخاصة.

فيظهر المنافس مرّتين، وأحد هذين العمودين هو أفضل حالته لا افتراضه. الثنائي المنشور الذي قد تنزّله مُصرَّف لعتاد أساس عام ويجزّئ ملفين أو ثلاثة فقط في وقت واحد؛ بناء المصدر نفسه للمعالج المضيف فعليًا وتمرير -T16 يتيح له استخدام التعليمات التي يملكها ذلك الجهاز فعلًا وتجزئة ستة عشر ملفًا مرة واحدة. على المحمول يستحق ذلك حتى 2.6x، كله من البناء والخيارات فحسب. احكم علينا بالعمود المضبوط، وهو المقارنة الأصعب؛ العمود كما يُشحن هو ما يختبره فعليًا من ينزّله. par2cmdline هو الأصلي، النسخة 1.2.0، مبني من المصدر على كل جهاز. rarpar هو تطبيق Weaver الخاص لـPAR2، مبني من المصدر بمحرّك Metal GPU مفعَّلًا. par2j من MultiPar مقتصر على Windows، فيظهر على صفوف المحمول Windows وحدها. تسابق صفوف M5 Max الأداتين ذواتَي بناء macOS arm64 الحالي إلى جانب عمودَي turbo؛ لم تُسابَق النسخة الكلاسيكية من par2cmdline على ذلك الجهاز.

كل خلايا nzbfast الست عشرة - أربعة أجهزة عند أربعة مستويات تلف - لنا، عدة منها بأكثر من 2× مقابل البناء المضبوط وبـ2.3× إلى 7.7× مقابل ما قد تنزّله فعليًا. خلايا التلف الثقيل هي المثيرة للاهتمام، والملاحظة أدناه تشرح الخوارزمية وراءها.

الأصلي عاد إلى الجدول، ويستحق أن نرى لماذا يوجد التفرّع أصلًا. أسقطت نسخة أقدم من هذه الصفحة عمود par2cmdline على أساس أنه أبطأ من كل شيء آخر في الجولة، وهذا صحيح وليس سببًا كافيًا: إنه التطبيق الذي تفرَّعت منه كل أداة أخرى تقريبًا، ويستحق القارئ الأساس المرجعي بدل تأكيدنا عليه. عند أثقل مستوى تلف يستغرق نحو 69 s حيث يستغرق التفرّع بـSIMD 3.2 s ونستغرق نحن 3.1 s. هذا العامل العشرون هو كل الحجة لنوى Galois-field المكتوبة يدويًا، وهي الحجة نفسها التي نسوقها لأدواتنا.

التلف الخفيف هو الحالة التي تهمّ. حفنة من المقالات الفاشلة أشيع بكثير من 101 كتلة ميتة، ولا شيء يشبه 1,500. معظم الإصلاح الخفيف ليس حساب Reed-Solomon على الإطلاق، إنه قراءة جيجابايت وتجزئته بـMD5، وهذا سبب تتبّع صف الثلاث كتل صف التحقق النظيف لا صفوف الإصلاح.

أثقل مستوى تلف نوع عمل مختلف، ويحصل على خوارزمية مختلفة. يتلف ذلك المستوى الأخير 1,500 كتلة عبر المجلدات الـ21 كلها ويستهلك نحو 91% من بيانات الاسترداد، حيث يصير حساب Reed-Solomon، لا التجزئة أو القرص، تقريبًا كل العمل. يحسب البناء المشحون الإصلاحات الأثقل بتحويل نظري-عددي بدل طيّ Galois-field الكلاسيكي - الحساب نفسه، مُقيَّمًا بصيغة تتوسّع أفضل بكثير عند عدد كتل مرتفع: بفارق 2.7× أمام البناء المضبوط على المكتب ذي العشرين نواة، وعلى المحمول Windows 2.7× أمام البناء المضبوط و2.2× أمام MultiPar. لا يزال التلف الخفيف يشغّل المسار الكلاسيكي، وهذا سبب بقاء المستويات الأخرى شبه ثابتة: لا يُجدي التحويل إلا فوق نحو 512 كتلة تالفة، فتحت ذلك لا يستخدمه الموزِّع.

لا يستحق مسار أسرع أن يكون إلا إن كان لا يمكن أن يكون خاطئًا. يحسب المساران الكمية نفسها ويتطابقان بايت لبايت بالبناء، وكل إصلاح في هذه الصفحة كان محكومًا بمطابقة الملفات المعاد بناؤها للمجموعة السليمة: 228 إصلاحًا مؤقَّتًا عبر أجهزة هذه الجولة، صفر حالات عدم تطابق. لا يعتمد البناء المشحون على ذلك السجل. يتحقق كل إصلاح من ناتجه مقابل تجزئات الملفات، وواحد فشل كان سيُعاد بالمسار الكلاسيكي تلقائيًا، ويسجّل الانحراف، ويحتفظ بالمسار الكلاسيكي لبقية ذلك التشغيل. الإعداد موجود في لوحة التحكم باسم وضع PAR السريع إن فضّلت عدم استخدامه أصلًا، والأجهزة ذات الذاكرة القليلة جدًا له ترفضه من تلقاء نفسها بدل المحاولة والفشل. أُعيد القياس في 2 أغسطس على البناء الحالي: يقع المكتبان ضمن نسب مئوية قليلة من هذا الجدول، ومع إيقاف وضع PAR السريع يعود المكتب ذو العشرين نواة إلى زمن المسار الكلاسيكي الأبطأ بالضبط، وهذا ما يقول إن الفوز هو الأسلوب لا الظروف.

احتاج عمود المحمول Windows تصحيحًا، وهو ضدنا. يخفض Windows العمل الخلفي المستمر إلى أنويته الاقتصادية بعد بضع ثوانٍ. تنسحب خدمتنا من ذلك عند الإقلاع ولا تستطيع أي أداة أخرى فعل ذلك، فنشرت نسخة أقدم من هذه الصفحة أزمنتها المخنوقة وكأنها أزمنة الأدوات نفسها. إعادة تشغيل ذلك الجهاز مع رفع كل أداة إلى أولوية عالية يحرّك الميدان كله: عند أثقل مستوى تلف ينتقل par2-turbo من 22.4 s إلى 6.41 وينتقل rarpar من 59.2 s إلى 14.4، وفي إحدى نسخ هذه الصفحة حوّل ذلك العمود من لنا إلى عمود خسرناه. يُقاس عمود المحمول كله بتلك الطريقة الآن - ويبقى التصحيح حتى بعد أن استعاد الصف الفوز بتغيير الخوارزمية أعلاه، لأن أزمنة الميدان على ذلك الجهاز أمينة فقط برفع الخنق.

سجلات استرداد RAR: الإصلاح دون PAR2

حين لا يستطيع PAR2 تغطية التلف، يكون سجل الاسترداد داخل ملف RAR نفسه خط الدفاع الأخير. حتى 1.0.8 كانت أداتنا تفشل على أي أرشيف فوق نحو 13 MB، فلم يكن ممكنًا تشغيل هذا الشوط أصلًا. التلف ثلاث ثقوب بحجم 3,000 بايت عند 20% و50% و80% عبر المنطقة المحمية. أنتجت كلتا الأداتين ناتجًا مطابقًا بايت لبايت للملف السليم، وناتجنا مطابق بايت لبايت لما تكتبه rar r نفسها. أفضل ثلاث، مكتب ذو 32 نواة، أُعيد سباق الأداتين معًا في 2 أغسطس.

أظهرت نسخة أقدم من هذه الصفحة حجم 512 MB كخسارة، وفسّرتها بثمن السير عبر المجلد على قطع بدل الاحتفاظ به كله في الذاكرة. كان ذلك التفسير صحيحًا حينها وهو الآن متجاوَز: كانت التكلفة CRC64 تسلسلي بت-بت في مسار الإصلاح، استُبدل بآخر يعمل بجدول، وذهبت الخسارة معه. لا تقاطع بعد الآن، واحتُفظ بمجموعة العمل المحدودة. حجم 2 GB موجود هنا لأن المجلدات التي تصادفها الخدمة فعليًا هي 8 GB إلى 20 GB، لا 512 MB، وشوط يتوقّف دون المدى الحقيقي ليس اختبارًا يُذكر.

ما حرّك هذا القصّ، والضابط الذي يقول ذلك. كان إيجاد الكتل التالفة قد صار أكبر مرحلة في هذا الإصلاح - أكبر من حساب الإصلاح نفسه - وكان يعمل على خيط واحد، يقرأ 64 KB من كل مجموعة عبر الملف، مرة لكل مجموعة. يمرّ الآن مرورًا تسلسليًا واحدًا بترتيب الملف مع حساب المجاميع التحققية لكل شريحة بالتوازي، ويُستنسَخ المجلد المُصلَح بدل نسخه حيثما يستطيع نظام الملفات فعل ذلك. هبط الاكتشاف وحده من نحو 300 ms إلى 18 ms على أرشيف 512 MB، وهذا معظم ما تحرّك أعلاه. الضابط هو العمود إلى جانب رقمنا: أُعيد سباق rar r في الجولات نفسها على الجهاز نفسه وعاد ضمن نسب مئوية قليلة من أزمنته السابقة، فالتغيّر في الفجوة هو تغيّرنا لا تغيّر المنصة.

يكرّر M5 Max النمط، سُوبِق في 31 يوليو بالعيّنة والضوابط نفسها: 0.050 / 0.066 / 0.171 / 0.581 s مقابل 0.211 / 0.335 / 0.751 / 1.735 لـrar r عبر الأحجام من 16 MB إلى 512 MB - أسرع بـ3.0× إلى 5.1×؛ لم يُسابَق حجم 2 GB على ذلك الجهاز. تسبق تلك الأرقام إعادة كتابة الاكتشاف الموصوفة أعلاه، فهي أرقام البناء الأقدم، محفوظة هنا كالجهاز الثاني لا كرقم حالي.

غائب rarpar الخاص بـWeaver عن هذا الجدول وحده، وليس اختيارًا: لا يطبّق هذا الإصلاح. عند مطالبته بإصلاح واحد من هذه الأرشيفات يجيب "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data"، ويترك الملف تالفًا. يظهر في كل مقارنة أخرى في هذه الصفحة: كل الأشواط الأربعة لـPAR2 أعلاه، وأشكال الاستخراج السبعة قبلها، وشوط مجلدات الاسترداد أدناه مباشرة، وهو العمل الذي يقول إنه يؤديه - والذي يفوز به.

مجلدات الاسترداد: إعادة بناء ملفات .rev المفقودة كلها

النصف الآخر من قصة استرداد RAR الخاصة، وحتى هذه الجولة كانت أكبر خسارة في هذه الصفحة. ملف .rev هو مجلد استرداد مستقل: يمكن لثلاثة منها إلى جانب مجموعة من 21 مجلدًا إعادة بناء أي ثلاثة مجلدات لم تصل أبدًا. العيّنة: 1 GiB مخزَّن في 21 مجلدًا بحجم 50 MB بأمر rar rv3، ثم حُذفت المجلدات 4 و11 و19 - ثلاثة مفقودة مقابل ثلاثة مجلدات استرداد، وهي أسوأ حالة يمكن للمجموعة الصمود أمامها. أفضل ثلاث، كل مجلد أُعيد بناؤه مقارَن مقابل المجلد السليم.

كانت خلية الـ32 نواة هنا 3.12 s مقابل 0.47 لـrar rc في القصّة السابقة لهذه الصفحة، ونُشرت كأبطأ بـ6.6× وأسوأ رقم فيها. كان السبب حلّ المحو (erasure solve) يعمل عند نحو 48 MB/s من الناتج المُعاد بناؤه حيث تدير RARLab 320؛ يعمل الآن على الحساب نفسه القائم على جدول الذي تستخدمه بقية شيفرة الاسترداد، وهو تحسّن سبعة أضعاف يحوّل الخسارة إلى فوز على كلا الجهازين. الهامشان 3% و14%، فهو فوز يُذكر ببساطة لا يُصدَّر عنوانًا، والسبب في ذكره أصلًا أن الخسارة ذُكرت أولًا.

هذا الشوط موجود لأن rarpar الخاص بـWeaver يطبّق هذا بالضبط وطلب أن يُقاس عليه. كان يفوز بارتياح حين نشرناه أول مرة، ونشرناه حينها لذلك السبب.

لم تكن مطابقة الملفات التكلفة أبدًا، ويستحق ذلك التسجيل لأنه كان المشتبَه به البديهي: لا تحمل مجلدات الاسترداد أي أسماء ملفات، فنحدّد أي الفتحات نجت بتجزئة كل مجلد على القرص بدل الثقة بما تُسمّى، ومقابل مجموعة غير تالفة، حيث المطابقة هي كل ما يحدث، يستغرق المرور كله 0.18 s.

ما تحرّك أيضًا، وأين لا يظهر. حدث تغييران آخران في المحرّك لا تستطيع هذه العيّنات رؤيتهما، مذكوران هنا كي لا تُقرأ الأرقام أعلاه كالقصة كلها: تحلّ أرشيفات RAR5 ذات عشرات الآلاف من الأعضاء كل عضو مرة واحدة بدل السير في القائمة لكل عامل، وهذا 3× زمن معالج أقل عند 40,000 عضو؛ وقارئ بتّات RAR1.3 يعمل كلمة كاملة في وقت واحد، وهذا 2×. لا يظهر أيّ منهما أعلاه، لأن الأشكال هنا تحمل 400 عضو ولا RAR1.3.

ما لا نفعله عمدًا: لا ننشئ PAR2 أبدًا. لا سبب لبرنامج تنزيل ليفعل ذلك، وParPar يملك ذلك العمل. نشتري السرعة أيضًا بالذاكرة على كلا المحرّكين: يبلغ الاستخراج ذروته حول 240 MB مقابل 41 MB لـunrar، ويبلغ التحقق ذروته حول 126 MB مقابل 7 MB لـturbo، لأن هذين محرّكان مضمَّنان يركبان تنزيلًا حيًّا لا أدوات مستقلة لمرة واحدة. شكل قاموس 128 MiB هو الأسوأ في ذلك، عند نحو 304 MB مقابل 139 MB لـunrar. وأثقل إصلاح يكلّف ذاكرة الآن أيضًا: الطريقة الأسرع لـ512 كتلة مفقودة فأكثر تعمل من بيانات الاسترداد محفوظة مقيمة، فيُسمَح لها بربع ذاكرة الجهاز، بحد أقصى 4 GB، وجهاز لا يملك ذلك يأخذ بهدوء الطريقة منخفضة الذاكرة بدلًا منها - الحساب نفسه والأزمنة نفسها كصفوف PAR2 الوسطى، لكن دون الـ3× في الأخيرة. إن أردت أصغر مجموعة مقيمة ممكنة لمهمة مستقلة، ما زالت الأدوات المخصَّصة تفوز بذلك العمود.

إثبات النقل · قيست على 1.2.2

المحرّك يواكب الخطوط الحقيقية

• نحو 8.7 Gbps مستمرة عبر أسطول خمسة مزوّدين على خط 10 GbE، بما في ذلك التحقق والاستخراج ضمن التدفّق - جولة الـ87 GB أعلاه، 24 أغسطس 2026، v1.2.2، 360 اتصالًا: 77.4 GB على السلك في 71 s مع تحقق الحمولة واستخراجها وهي واصلة. ليس رقم اندفاع: المهمة كلها بذلك المعدل.
• عند 1 Gbit فما دون، الخط هو الحدّ ويجلس nzbfast عليه: نحو 96% من خط 500 Mbit ونحو 96% من خط 250 Mbit عبر التحقق والاستخراج، بجزء من ذاكرة وقرص كل منافس - قسم ما دون الجيجابت أعلاه.
• تكلفة المعالج للمهمة كلها على مهمة الـ87 GB هي 1.7 ثانية معالج لكل جيجابايت مع تشغيل منظّم الاتصالات - التنزيل عبر TLS، والتحقق، وجهوزية الإصلاح، والاستخراج مشمولة - مقابل 3.0 إلى 28 للميدان في الجولة نفسها؛ ينفق الذراع كامل السعة أعلاه 4.3.

حملت قصّات أقدم من هذه الصفحة مجموعة أوسع من إثباتات النقل - تشغيلات إشباع متعددة الخطوط، ومكاسب أنابيب لكل RTT، وإثبات ضغط عكسي، وقياسات سقف فكّ التشفير - سُوبِقت على بُنى تجاوزها v1.2.2 منذ ذلك الحين. بموجب قاعدة هذه الصفحة تُسحَب بدل أن تُترك تشيخ، وتعود عند إعادة قصّها على الإصدار الحالي؛ الادعاءات الثلاثة أعلاه هي ما أُعيد قياسه بالفعل على v1.2.2.