قياس مستقل: Python 3.15 أسرع من 3.14 بنحو 3% فقط، ونسخة free-threading أسرع 4.5 مرات
المغزى: الفارق الكبير في أداء Python لم يعد في رقم النسخة بل في اختيار المفسّر، فالترقية وحدها تعطي تحسنًا طفيفًا، أما إزالة الـ GIL فتغيّر النتيجة في العمل المتوازي.
نشر المهندس Miguel Grinberg في 5 أكتوبر 2026 قياسًا لأداء Python 3.15 مقارنة بالنسخ السابقة. واستخدم اختبارين: حساب fibonacci للعدد 40، وترتيب 10,000 رقم بخوارزمية bubble sort.
على خيط واحد، أنهت نسخة 3.15 اختبار fibonacci في 6.94 ثانية، مقابل 7.17 ثانية لنسخة 3.14، أي تحسن بنحو 3%. أما نسخة 3.10 فاحتاجت 15.94 ثانية. وفي bubble sort كانت الأرقام 1.97 و2.06 و3.99 ثانية على الترتيب. فالمكسب الكبير تراكم عبر خمس نسخ متتالية، لا في قفزة واحدة.
والرقم الأبرز ظهر عند التشغيل على أربعة threads. فنسخة 3.15 العادية أنهت العمل في 32.54 ثانية، بينما أنهته نسخة free-threading في 7.24 ثانية، أي أسرع 4.5 مرات. وفي bubble sort كانت أسرع 1.74 مرة.
وسبب الفارق هو الـ GIL، وهو قفل داخل المفسّر العادي يسمح لخيط واحد فقط بتنفيذ كود Python في كل لحظة. لذلك كانت الخيوط تتناوب على العمل بدل أن تعمل معًا على أنوية مختلفة. ونسخة free-threading تُبنى دون هذا القفل، فتعمل الخيوط بالتوازي فعلًا.
أما الـ JIT التجريبي، الذي وضع له PEP 836 هدفًا رقميًا، فأعطى تحسنًا بمقدار 1.20 و1.28 مرة على خيط واحد في الاختبارين.
وخلاصة Grinberg أن التحسن في المفسّر العادي “طفيف نسبيًا” مقارنة بـ 3.14، ولا يرى سببًا للاستعجال في ترقية بيئات الإنتاج.
ويكشف القياس أن عبارة “ترقية Python” لم تعد تكفي لوصف قرار الأداء. فالفريق الذي يحدّث رقم النسخة يحصل على مكسب صغير. أما الفريق الذي لديه عمل يتوازى فعلًا، فالقرار المؤثر عنده هو اختيار المفسّر، مع ما يتطلبه ذلك من التأكد أن المكتبات التي يعتمد عليها تعمل دون الـ GIL.