قياس الأداء

قياس أداء مصغّر وصريح لـ RTLY-Kit مقابل morilog/jalali، مع المنهج كاملًا والتحفظات وأمر من سطر واحد لإعادة التشغيل على جهازك.

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

ما الذي تتم مقارنته

morilog/jalali (opens in a new tab) الإصدار v3.5.0 (أكثر حزم التقويم الجلالي استخدامًا) مقابل RTLY-Kit، في ثلاث عمليات:

السيناريو	RTLY-Kit	morilog/jalali
من نص ميلادي إلى جلالي `Y/m/d`	`Jalali::make('2025-03-21')->format('Y/m/d')`	`Jalalian::fromDateTime('2025-03-21')->format('Y/m/d')`
من جلالي `y/m/d` إلى ميلادي `Y-m-d`	`Jalali::create(1404, m, d)->toGregorian()->format('Y-m-d')`	`(new Jalalian(1404, m, d))->toCarbon()->format('Y-m-d')`
`addDays` ثم التنسيق	`Jalali::create(1404, 1, 1)->addDays(n)->format('Y/m/d')`	`(new Jalalian(1404, 1, 1))->addDays(n)->format('Y/m/d')`

جانب RTLY-Kit من كل سيناريو، كما تكتبه عادةً:

PHP

<?php
require __DIR__.'/vendor/autoload.php';

use RtlyKit\Calendar\Jalali;

echo Jalali::make('2025-03-21')->format('Y/m/d'), "\n";                       // 1404/01/01
echo Jalali::create(1404, 1, 1)->toGregorian()->format('Y-m-d'), "\n";       // 2025-03-21
echo Jalali::create(1404, 1, 1)->addDays(100)->format('Y/m/d'), "\n";        // 1404/04/08

النتائج

تشغيل واحد، والقيمة الوسطى من 5 تكرارات، في كل منها 20,000 دورة. البيئة: PHP 8.2.30 CLI داخل Docker على Windows 11، مع opcache.enable_cli=1.

السيناريو	RTLY-Kit (µs/op)	morilog/jalali (µs/op)	النسبة
من نص ميلادي إلى جلالي `Y/m/d`	13.33	153.84	11.5x
من جلالي `y/m/d` إلى ميلادي `Y-m-d`	12.80	58.55	4.6x
`addDays` + التنسيق	33.18	479.04	14.4x

بلغت ذروة الذاكرة للعملية كلها، مع تحميل المكتبتين، 4 MiB.

أظهر تشغيل سابق غير منهجي، بلا opcache ومع مزيج مختلف من السيناريوهات، فجوة أكبر (نحو 25x). والتفاوت بين التشغيلات هو الدرس نفسه: النسبة تعتمد على السيناريو وعلى إعدادات PHP.

التحقق المتقاطع من الصحة

لكل يوم من 1900-01-01 إلى 2099-12-27 (73,000 يوم متتالٍ) يطابق التاريخ الجلالي في RTLY-Kit ما تعطيه CalendarUtils::toJalali في morilog: 0 اختلافات. تطبّق المكتبتان قاعدة السنة الكبيسة الحسابية ذات الدورة 33 سنة، فالتطابق يعني أن إحداهما متسقة مع الأخرى. أما مطابقة التقويم الإيراني الرسمي فمفحوصة بمقارنة أخرى للسنوات 1206 إلى 1497 (راجع الدقة والبيانات).

لماذا هذا الفرق؟

لم نُجرِ تحليل أداء (profiling) لهذا، فما يلي تفسير محتمل لا مثبت. يغلّف RTLY-Kit كائن DateTimeImmutable عاديًا ويحوّل بحساب الأعداد الصحيحة. أما morilog فيبني كائنات Carbon ويعالجها، وهي أكبر بكثير (آليات التحليل والإعدادات المحلية)، فجزء من الفرق اختيار معماري وليس خوارزمية التحويل وحدها. وإن كنت تستخدم Carbon في كل مكان أصلًا، فقد يكون الفرق الذي يهمّك أصغر.

إعادة التشغيل

يوجد القياس في tools/benchmark داخل المستودع. يثبّت ملف composer.json فيه RTLY-Kit من شجرة العمل، إضافةً إلى morilog/jalali، في مجلد vendor/ خاص به (وهو ليس جزءًا من الحزمة). يطبع السكربت إصدار PHP وإعدادات opcache وJIT والقيمة الوسطى للتكرارات.

Bash

docker compose -f tools/docker-compose.yml run --rm php sh -c 'cd tools/benchmark && composer install -n && php -d opcache.enable_cli=1 run.php 20000 5'

لا يمكن مقارنة الأرقام الصادرة عن أجهزة مختلفة.

القيود

ثلاثة سيناريوهات فقط؛ لا أحمال تعتمد على التنسيق المكثف أو التحليل المكثف أو المصفوفات الكبيرة.
جهاز واحد وبناء PHP واحد؛ وDocker على Windows يضيف ضجيجًا.
لا قياس للذاكرة لكل كائن، سوى الذروة الإجمالية.
قِيست morilog/jalali وحدها؛ ولم تُقَس حزم أخرى.