تقرير الأداء

كلفة تطبيقات NSH مقيسة بالأرقام. لمعرفة كيف يحافظ NSH على سرعتها وكيف تقيس أداء تطبيقك، راجع الأداء.

#القياسات المرجعية

من القياسات المرجعية الخاصة بـ NSH (على Apple silicon ما لم يُذكر خلاف ذلك):

#Linux (GTK 4)

قيست على حاسوب مكتبي يعمل بنظام Linux (x86_64، 24 خيطًا، معالج رسوميات NVIDIA)، بنسخ release، والمعرض في نافذة 1896 × 1030 على شاشة 120 Hz، وكل قراءة أُخذت تلقائيًا بواسطة examples/gallery/tools/perf.py (nsh test --target linux --fps، سطر واحد كل ثانية؛ المعالج CPU يخص العملية بأكملها، كنسبة مئوية من نواة واحدة). Frame p95 هو زمن الخيط الرئيسي لكل إطار مرسوم عند المئين 95: وإذا كان أقل من 8.3 ms فإن الإطار يتسع داخل تحديث الشاشة بمعدل 120 Hz.

#العروض المتحركة

#كل صفحة

كل صفحة من صفحات المعرض، عند فتحها وأثناء تمرير الاختبار لها، في نافذة 1200 × 800 على شاشة 144 Hz (الجهاز نفسه). يرسم NSH إطارًا فقط عندما يتغير شيء على الشاشة، لذا فإن FPS هنا هو المعدل أثناء حدوث حركة: إطار واحد لكل فترة وسيطة بين الإطارات المرسومة (perf.py الخاص بـ moving)؛ وعند 144 للشاشة، يأتي كل إطار من إطارات الحركة أو التمرير بعد تحديث واحد من الإطار السابق. أكثر من تحديث واحد هي نسبة الإطارات التي استغرقت أكثر من تحديث واحد (6.9 ms). يُشغَّل GIF وWebP في Images بمعدلات إطاراتها الخاصة (نحو 50 FPS هنا)، وكذلك الفيديو. صفحات Physics وOverlays وMenus قصيرة: ففي 1200 × 800 يصل التمرير إلى نهايتها خلال بضعة إطارات، لذلك تُقاس في نافذة 900 × 500 حيث يتوفر لها متسع للتمرير.

#الذاكرة

في حالة السكون، بعد 3 ثوانٍ من البدء (مشغّلات release، نافذة 480 × 640). Private هي الذاكرة التي تملكها العملية وحدها (USS)؛ أما resident فتضيف صفحات المكتبات المشتركة (GTK، وتعريف GPU)، التي يشاركها كل تطبيق GTK على الجهاز:

إعادة زيارة صفحة لا تضيف ذاكرة؛ أما أول زيارة لصفحة فتزيد حجم العملية بمقدار ما تخزّنه عمدًا في الذاكرة المؤقتة (صور مفكوكة الترميز، بحد أقصى 128 MB) وبالمكتبات التي تُحمَّل عند أول استخدام (WebKitGTK لعروض الويب).

#حجم التطبيق

تطبيق hello world أنشأه nsh init بكل قالب، وتطبيقان يستخدمهما الناس، كما يبنيهما nsh package --target linux لمعمارية x86_64. المشغّل (runner) هو الملف التنفيذي الوحيد للتطبيق؛ والأرشيف هو .tar.gz الذي يُوزَّع به. تُبنى تطبيقات hello world مع تحسين وقت الربط (link-time optimization) وتُجرَّد من الرموز (CARGO_PROFILE_RELEASE_LTO=fat، CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1، CARGO_PROFILE_RELEASE_STRIP=true):

تحتوي مشغّلات TSX على بيئة QuickJS التشغيلية والوحدات الأصلية والمُصيِّر؛ أما شيفرة التطبيق نفسه فهي حزمته (bundle) الموجودة بجانب المشغّل، وحجمها أقل من 1 KB في تطبيق hello world.

ما الذي يصنع هذه الأرقام:

• المُصيِّر: مع تعريف NVIDIA يرسم NSH بمُصيِّر GL الخاص بـ GSK، وتكلفة إطاراته جزء يسير من تكلفة مُصيِّر Vulkan هناك (عرض Animations: ~1 ms من الرسم لكل إطار بدلًا من ~9.5 ms). ولا يزال GSK_RENDERER هو من يختار.
• تحويل Canvas إلى نقاط (rasters): يُحوَّل كل canvas إلى نقاط مرة واحدة في بلاطات بحجم 256 px محفوظة على GPU. وتعيد القيمة المتحركة رسم المنطقة التي تغطيها العمليات التي تقرؤها فقط، فوق البكسلات المحفوظة للجزء الثابت من الرسم؛ وأي canvas خارج مجال الرؤية ينتظر حتى يُمرَّر إلى العرض.
• مسارات تُحفظ جانبًا مرة واحدة: fillRect وfillText بعد مسار طويل يتركانه في مكانه حتى يُستخدم مجددًا (خط من 400 نقطة ثم 240 شريطًا: 0.63 ms).

#macOS (AppKit)

قيست على MacBook Pro (Apple M3، 24 GB) على شاشته المدمجة ProMotion بمعدل 120 Hz، بنسخ release، والمعرض في نافذة 1200 × 800، وكل قراءة أُخذت تلقائيًا بواسطة examples/gallery/tools/perf.py (nsh test --target macos --fps، سطر واحد كل ثانية؛ المعالج CPU يخص العملية بأكملها، كنسبة مئوية من نواة واحدة، وGPU حصتها من معالج الرسوميات). المراحل هي أزمنة الخيط الرئيسي لكل إطار: tick (الحركات الأصلية لرابط العرض display link) وcanvas (إعادة تشغيل الرسومات).

#العروض المتحركة

في Stocks يبلغ زمن الخيط الرئيسي للإطار نحو 1.6 ms للـ ticks، منها ~0.45 ms لإعادة تشغيل الأجزاء المتحركة من canvases؛ أما بقية كل canvas فيرسمه Core Animation على خيوطه الخاصة.

#كل صفحة

كل صفحة من صفحات المعرض، عند فتحها وأثناء تمرير الاختبار لها، في نافذة 1200 × 800 نفسها. وكما في Linux، فإن FPS هو المعدل أثناء حدوث حركة (إطار واحد لكل فترة وسيطة بين الإطارات المرسومة)؛ وعند 120 للشاشة، يأتي كل إطار من إطارات الحركة أو التمرير بعد تحديث واحد من الإطار السابق. أكثر من تحديث واحد هي نسبة الإطارات التي استغرقت أكثر من تحديث واحد (8.3 ms). الصفحة الساكنة لا ترسم أي إطار وتستهلك 2–5% من CPU. يُشغَّل GIF وWebP في Images عبر Core Animation، والفيديو عبر AVFoundation، بمعدلات إطاراتها الخاصة.

#الذاكرة

في حالة السكون، بعد 3 ثوانٍ من البدء (مشغّلات release). Footprint هي الذاكرة التي يحاسب بها macOS العملية (ما يعرضه Activity Monitor)؛ أما resident فتضيف صفحات المكتبات المشتركة للنظام:

خلال جولة المعرض تشغل العملية ما بين 84 و230 MB حتى صفحة Canvas، ثم ~350–360 MB ابتداءً من صفحة Text View، وذلك مع ما تخزّنه عمدًا في الذاكرة المؤقتة (صور مفكوكة الترميز، بحد أقصى 128 MB؛ ومستندات صفحة Text View) ومع الأطر (frameworks) التي تُحمَّل عند أول استخدام (WebKit لعروض الويب)؛ أما نقاط raster الخاصة بصفحة Canvas، التي تصل إلى ~310 MB عند ظهور الـ canvases الثلاثة على الشاشة، فتزول عند إغلاق الصفحة.

#حجم التطبيق

تطبيقات hello world التي ينشئها nsh init بكل قالب، كما يبنيها nsh package --target macos لمعالجات Apple silicon (arm64)، مع تحسين وقت الربط (link-time optimization) وإزالة الرموز كما في Linux، إضافةً إلى التطبيقين المذكورين أعلاه كما يُشحنان لمعالجات Apple silicon. الملف التنفيذي هو المشغّل (runner) داخل .app؛ والملف المضغوط هو .app بعد ضغطه (ditto -c -k):

ما الذي يحقق هذه الأرقام:

• إطارات للتغييرات فقط: يعمل display link أثناء تشغيل حركة أصلية (native animation) ويتوقف معها؛ وتتوقف الحركة مع صفحتها (حذف العرض الخاص بها ينهي إطاراتها المفتاحية، وتتوقف الحلقة في cleanup الخاص بمكوّنها).
• رسم الـ canvas حيث يكلّف أقل: الـ canvas الذي يُرسم كثيرًا (حركة، بيانات حية) يُرسم على خيوط Core Animation (drawsAsynchronously)، مما يُبقي الخيط الرئيسي حرًا؛ أما الذي يُعاد رسمه بين الحين والآخر فيُرسم فورًا، دون ذاكرة الرسوميات التي يحتفظ بها الرسم غير المتزامن. وتعيد القيمة المتحركة رسم المنطقة التي تغطيها العمليات التي تقرؤها فقط.
• الاحتفاظ بأجزاء الـ canvas الثابتة: متى بقي الرسم دون تغيير، يُحفظ الجزء الطويل الذي يسبق أول عملية متحركة كطبقة (layer)؛ ويرسم كل إطار هذه الطبقة ويعيد تشغيل الجزء المتحرك المتبقي فقط، فورًا على الخيط الرئيسي (مقياس صفحة Canvas وساعتها ومصفوفة نقاطها: بلا عمل على GPU وبنصف الذاكرة).
• رسم المحتوى عند تغيّره: تُرسم النصوص والـ canvas في طبقات خاصة بها، وتُرسم من جديد عند تغيّر محتواها أو حجمها، لا عند تحريكها أو تمريرها.

#Windows (Win32, Direct2D)

القياسات على حاسوب مكتبي بنظام Windows 11 (Intel Core i7-13700KF، ذاكرة 32 GB، NVIDIA GeForce RTX 3060 Ti) بشاشة 4K وتردد 144 Hz بتكبير 150%، وبنسخ release، ومعرض الأمثلة (gallery) في نافذة 1200 × 800 (1800 × 1200 بكسل)، وكل قراءة تُؤخذ تلقائيًا بواسطة examples/gallery/tools/perf.py (nsh test --target windows --fps، سطر واحد كل ثانية؛ استهلاك CPU للعملية كاملة، بنسبة مئوية من نواة واحدة). المراحل هي ما يستغرقه الخيط الرئيسي لكل إطار: paint (رسم Direct2D للنافذة) وضمنه canvas (تسجيل الرسومات وإعادة تشغيلها).

#العروض المتحركة

ينفّذ Stocks من 16 إلى 17 عملية commit في الثانية، تستغرق كل منها حتى 2.1 ms في JS و1.7 ms في النواة على خيط المحرّك (p95).

#كل صفحة

كل صفحة من صفحات المعرض، عند فتحها وأثناء تمرير الاختبار لها، في نافذة 1200 × 800 نفسها. كما في Linux و macOS، FPS هو المعدّل أثناء وجود حركة (إطار واحد لكل فجوة وسيطة بين الإطارات المرسومة)؛ وعند 144 للشاشة، يأتي كل إطار من حركة أو تمرير بعد تحديث واحد من سابقه. تجاوز تحديثًا واحدًا هي نسبة الإطارات التي استغرقت أكثر من تحديث واحد (6.9 ms). الصفحة الساكنة لا ترسم أي إطار وتستهلك 0–2% من CPU. صور GIF وWebP في صفحة Images تعمل بمعدلات إطاراتها الخاصة (نحو 40 FPS هنا). تُقاس صفحات Physics وOverlays وMenus وStorage في نافذة 900 × 500، حيث تتسع للتمرير.

#الذاكرة

في حالة السكون، بعد 3 ثوانٍ من البدء (مشغّلات release، نافذة 1200 × 800). Private working set هي الذاكرة التي تستخدمها العملية وحدها (عمود Memory في Task Manager)؛ وprivate bytes ما حجزته منها؛ وworking set تضيف صفحات مكتبات النظام التي تتشاركها مع عمليات أخرى (Direct3D وDirect2D وDirectWrite وبرنامج تشغيل GPU):

خلال جولة المعرض يبلغ working set نحو 108–115 MB في Stocks، ونحو 230 MB من صفحة Canvas، ونحو 320–340 MB من صفحة Text View، ونحو 390–405 MB بعد أن تفتح Web and video عنصر WebView2 (الذي تعمل صفحاته في عمليات WebView2 الخاصة به)، مع ما تخزّنه مؤقتًا عن قصد (الصور المفكوكة، بحد أقصى 128 MB؛ ومستندات صفحة Text View).

#حجم التطبيق

تطبيقات hello world التي ينشئها nsh init بكل قالب، كما يبنيها nsh package --target windows لمعمارية x86_64 (مشغّلات Rust مع تحسين وقت الربط وإزالة الرموز، كما في Linux). الملف التنفيذي هو <Name>.exe التطبيق؛ والملف المضغوط هو .zip المكتوب بجانب مجلده:

ما الذي يحقق هذه الأرقام:

• إطارات للتغييرات فقط، تُرسم حيث تغيّرت فقط: يعمل المؤقّت (ticker) المتزامن مع المُركِّب (compositor) أثناء تشغيل حركة أصلية أو انتقال أو دالة رد نداء للإطار. يرسم الإطار مناطق العروض التي تغيّرت (حيث كانت وحيث صارت)، فوق البكسلات التي تحتفظ بها النافذة، ولا يقدّم للمُركِّب إلا هذه المناطق (Stocks: نحو 34 عرضًا في الإطار).
• يسجّل الـ canvas جزأه المتحرك: يُسجَّل الرسم كقوائم أوامر Direct2D، متجهيًا وحادًا عند أي مقياس. وعندما تتغيّر قيمة متحركة، لا يُعاد تسجيل إلا العمليات ابتداءً من أول عملية تقرأ قيمة متحركة؛ أما ما يسبقها فيُحتفظ به (Stocks: نحو 26 ms من التسجيل في الثانية لـ 22 مخططًا مصغرًا نابضًا والمخطط الرئيسي).
• يُرسم ما يظهر فقط: تُستثنى من الإطار العروض الأبناء لعرض تمرير أو عرض قص (clipping) التي تقع خارج مجال الرؤية، ولا ترسم العروض التي لا محتوى خاصًا بها أكثر من خلفيتها وحدودها.

#iOS (UIKit)

القياسات في محاكي iOS (iPhone 18 Pro Max، على MacBook Pro المذكور أعلاه)، بنسخ release، وبالجولة نفسها (perf.py --target ios: nsh test --target ios --fps، لمسات إصبع كما يتلقاها UIKit). يعرض المحاكي بتردد 60 Hz؛ وعلى iPhone بشاشة ProMotion تعمل display links في NSH بتردد 120 Hz للشاشة (التطبيقات التي يبنيها nsh package ومضيف التطوير تطلب ذلك عبر CADisableMinimumFrameDurationOnPhone). المراحل هي tick (الحركات الأصلية) وdrain (تطبيق دفعات المحرّك) وscroll (ما يتبع عرض التمرير: القوائم، والخلايا اللاصقة، والقيم المرتبطة).

FPS هو المعدّل أثناء وجود حركة، كما سبق: عند 60 للمحاكي، يأتي كل إطار بعد تحديث واحد من سابقه. كل صفحة لا يتحرك فيها شيء لا ترسم أي إطار وتستهلك 1–2% من CPU في حالة السكون. تشغل العملية 40 MB في الصفحة الرئيسية للمعرض ونحو 180 MB بعد الجولة كاملة (صور مخزّنة مؤقتًا عن قصد، ومستندات صفحة Text View).

على iPhone 17 Pro (ProMotion، 120 Hz)، مع مضيف التطوير وعرض توضيحي واحد على الشاشة، ترسم الصفحات المتحركة في كل تحديث:

ينفّذ Stocks 20 عملية commit في الثانية (نبضة كل 50 ms)، تستغرق كل منها 1.5 ms في JS و1.4 ms في النواة على خيط المحرّك (p95 هو 2.2 و2.0 ms)، ويكون هذا الخيط مشغولًا بنسبة 4–6% من الوقت.

#قياس تطبيق

لقياس تطبيق بالطريقة نفسها، شغّل اختباراته أو خطواته باستخدام --fps و-v على --target linux أو macos أو windows أو ios:

cargo build --release -p nsh-cli
python3 examples/gallery/tools/perf.py --target macos --only Stocks,Canvas   # the gallery, page by page
echo 'await app.wait(5000)' | nsh -v test App.tsx --target linux --fps        # any app