لماذا أصبح Monosnap بطيئًا جدًا — والحل

ضريبة Electron، متفاقمة

لم يبدأ Monosnap’يبدأ كتطبيق Electron. في بداية حياته، كان الكثير من كود الالتقاط والتحرير أصليًا. بمرور الوقت، أعيد بناء مكونات واجهة المستخدم فوق عارض Chromium — مما جعلها أسهل للتكرار عليها ولكن أضافت تكلفة بدء تشغيل كبيرة ودائمة.

لا يصبح Electron’أخف بمرور الوقت. كل عام يضيف Chromium ميزات، ويشحن المزيد من الكود، والمزيد من الذاكرة الأساسية، وتهيئة أكثر تعقيدًا. التطبيق الذي كان مقبولاً بحجم 60 ميجابايت في عام 2019 أصبح الآن 180 ميجابايت كحد أدنى عند الإطلاق، وينمو من هناك. هذا’قبل النظر في تسرب الذاكرة الذي غطيناه في صفحة تسرب الذاكرة.

عندما تضغط Ctrl+Alt+5، يجب على Monosnap تسخين عارض Chromium لرسم تراكب الالتقاط. في تطبيق بارد، هذا’يستغرق عدة مئات من المللي ثانية. في تطبيق دافئ تسرب بالفعل إلى مئات الميغابايت، فإنه’يستغرق وقتًا أطول. بحلول الساعة الخامسة من يوم العمل، يتم رسم التراكب ببطء كافٍ بحيث يمكن للمستخدمين ملاحظة الفرق.

محرر التعليقات التوضيحية هو الأسوأ

نافذة المحرر بعد الالتقاط هي بالكامل تقريبًا عرض ويب من Chromium. عندما تسقط سهمًا أو ترسم مستطيلاً، ترسل الأداة الأحداث عبر Electron’حدود IPC إلى العملية الأصلية والعودة مرة أخرى. هذه الرحلة ذهابًا وإيابًا سريعة في عملية جديدة وتصبح بطيئة بشكل ملحوظ بمجرد تحميل العملية.

للمستخدمين الذين يقومون بالتعليقات التوضيحية المكثفة — تقارير الأخطاء، البرامج التعليمية، المستندات — يتراكم هذا. عشر دقائق من التعليق التوضيحي تبدو وكأنها عشرين.

Maxisnap: لا يوجد Electron، لا يوجد عبء

Maxisnap’محرر Maxisnap هو نافذة PyQt6 أصلية. تستخدم لوحة التعليقات التوضيحية QPainter مباشرة على QPixmap. لا يوجد’عرض ويب، ولا حدود IPC بين منطق الأداة وسطح العرض. عندما تسقط سهمًا، يظهر في دورة الرسم التالية. لا توجد رحلة ذهاب وعودة.

يستغرق التشغيل البارد من علبة النظام إلى جاهزية الالتقاط حوالي ثانية واحدة على جهاز نموذجي. الالتقاط إلى المحرر يستغرق أقل من 200 ms. تبقى هذه الأرقام كما هي في الساعة 1، الساعة 4، الساعة 8، والساعة 72. التطبيق لا’يتدهور بمرور الوقت لأنه لا يوجد’شيء يتراكم.