Ember.js: فقدان الأداء بين الإصدارين 2.x و 3.x.

بعد عدة عمليات تشغيل في Chrome 81 على جهازي ، حصلت على:

2.18 أفضل وقت: 283 مللي ثانية
3.18 أفضل وقت: 471 مللي ثانية

كان ذلك يعمل مع إغلاق DevTools.

ثم قمت بتحويل أداة 3.18 إلى Ember Octane عن طريق:

• استخدام الفئات الأصلية للمكونات ووحدات التحكم.
• باستخدام @tracked وعدم استخدام @computed .
• تحويل المكون t-r إلى مكون قالب فقط لأنه لم يكن بحاجة إلى فئة دعم.
• استخدام صيغة قوس الزاوية عند استدعاء المكونات.
• استخدام args المسماة و this. عند الاقتضاء في القوالب.

بعد ذلك ، كان أفضل وقت حصلت عليه من 3.18.1 هو 276 مللي ثانية ، لذلك تحسن كبير بما يتماشى مع الرقم 2.18.

لم تكن اختبارات الأداء هذه علمية بشكل خاص ، ولم أحقق في أي تغيير كان الأكثر أهمية من حيث الأداء.

يعد التنميط في twiddle عرضة للخطأ إلى حد ما ، فهل يمكننا الانتقال إلى تطبيق ember-cli عادي (باستخدام فرع لكل من الإصدارين) لملف التعريف ضده؟

rwjblue أحصل على نفس النتائج على تطبيق ember- هنا

@ richard-viney قد تكون هناك تحسينات يجب وضعها في الاعتبار ولكن المشكلة هي أنه لم يتم استخدام رمز مهمل في كلا الإصدارين وتجربة فقدان في الأداء يبدو أمرًا غير مقبول.

• قد يؤدي استخدام مكون القالب فقط إلى تعزيز الأداء ولكن tr بالتأكيد ستحتاج إلى فئة دعم لحساب بعض الأنماط الداخلية. تم تبسيط المثال لتوضيح المشكلة.
• مع كل عمليات إعادة البناء ، تحصل على 2 بالمائة (283 مللي ثانية -> 276 مللي ثانية) مكاسب في الأداء مقابل 2.18. ضع في اعتبارك ترقية تطبيق 2.18 حالي إلى 3.x. إعادة هيكلة جميع المكونات فقط للحصول على زيادة بنسبة 2 في المائة ليس مجديًا بالتأكيد.

barisnisanci موافق ، لم أكن أقصد أن أقترح أن هذا النوع من إعادة البناء يجب أن يكون ضروريًا لتجنب حدوث تراجع كبير في الأداء عند الترقية. لقد كانت تجربة لمعرفة ما إذا كان هناك أي تأثير من استخدام الاتفاقيات الحديثة ، حيث قد يساعد ذلك في عزل المشكلة و / أو السماح بالتعامل معها إذا لزم الأمر.

سيكون من المثير للاهتمام معرفة إصدار (إصدارات) Ember الذي قدم تراجع الأداء عن طريق اختبار إصدارات LTS المتداخلة ، مثل 3.4 و 3.8 و 3.12 و 3.16.

يعملbarisnisanci Ember ember serve في وضع التطوير افتراضيًا. أثناء التطوير ، يتم تمكين الكثير من الأدوات الإضافية التي يمكن أن تؤدي إلى تراجع الأداء بشكل خطير. لا نعتبر هذا عادةً انحدارًا أو مشكلة ، إلا إذا كان سيئًا بما يكفي للتأثير على بيئة عمل المطور. لذا أولاً ، أود التحقق من أنك تقوم بتشغيل كلا الإصدارين في وضع الإنتاج.

لقد قمت بتنزيل المثال الخاص بك وقمت بتقديم 2.8 و 3.18 جنبًا إلى جنب في وضع الإنتاج. ما وجدته هو أنه يبدو أنك قد تكون على صواب ، في المتوسط ​​، يبدو التوقيت بين العمليتين المساعدتين (وهو ما يتم قياسه هنا) أكبر في 3.18 مما كان عليه في 2.8. يعتمد ذلك على أخذي لبعض العينات على جهاز الكمبيوتر المحمول الخاص بعملي دون وجود العديد من الضوابط ، لذلك من الصعب الجزم بذلك ، ولكن من الممكن أن يكون تغييرًا طفيفًا.

ومع ذلك ، بالنظر إلى مقاييس أخرى أكثر أهمية ، لا أرى أي تغيير. بالنظر على وجه التحديد إلى الوقت الإجمالي لعرض المحتوى ، فإنها تبدو متشابهة بشكل عام. على سبيل المثال ، يكون وقت أول رسم هو نفسه تقريبًا.

من المهم أن تضع في اعتبارك أن لدينا الكثير من العمل المنتشر في العديد من الأماكن ، وعندما نجري تغييرات ، يتحرك هذا العمل أحيانًا ولكنه لا يؤثر على المقاييس _ الشاملة. هذا هو السبب في أننا نستخدم TracerBench للتحقق من تغييرات الأداء ، لأنه مصمم لمراعاة المراحل العامة للتصيير ولحساب جميع التغييرات على مستوى _macro_ ، بدلاً من مستوى _micro_ ، مثل التوقيت بين تشغيل المساعدين.

ربما يجب أن نحاول إجراء اختبار TracerBench قريبًا على مدار فترة زمنية أطول ، فقط للتحقق من هذه النتائج وللتأكد من أننا لم نتراجع بشكل عام (نستخدمه عادةً لإجراء تغييرات أصغر حيث نتوقع حدوث تراجع محتمل). يجب أيضًا أن نحاول تشغيله على فترات منتظمة ، حتى نتمكن من رؤية خط الاتجاه.

pzuraq للتو تحديث المستودع مع rowsCount:300 و columnsCount:20 يجب أن يكون الفرق أكثر وضوحًا الآن. كلاهما يعمل بـ --environment production

• 3.18 الطلاء الأول: 3489 مللي ثانية
  
• 2.18 الطلاء الأول: 2814 مللي ثانية
  

لاحظ أيضًا أن JS Heap لم يتم إصداره مطلقًا في 3.18 ولكن ربما بعض الحظ السيئ في GC.

يمكنني إضافة روابط النمط ، وحقن الخدمة ، والمزيد من العمليات الحسابية الثقيلة على المكونات بدلاً من زيادة التهم ، ولكنها قد تحجب المشكلة الأساسية.

تمامًا كما ذكرت ، تعتبر المقاييس العامة مهمة جدًا من التغييرات الطفيفة. ومع ذلك ، فإن الاختلافات الطفيفة تؤدي إلى انخفاض كبير في الأداء في حالتنا. زاد وقت العرض الأولي لتطبيقنا التجاري من 15 ثانية إلى 20 ثانية بعد الترقية إلى 3.18. نأمل أن تفكر في الانحدار من حيث النسبة المئوية بدلاً من التغييرات الطفيفة في الميلي ثانية.

شركتنا تعاني من هذه المشكلة. قمنا بتحديث إصدار ember من 2.18 إلى 3.16. ثم أصبحت أوقات العرض أطول من "50" بالمائة. عندما نستخدم هياكل معقدة ، يصبح الفرق بين أوقات العرض أكثر وضوحًا بدلاً من التغييرات الطفيفة في الميلي ثانية. أي تحديثات بشأن هذه المسألة؟ لدينا معايير تُظهر زيادة بنسبة 50٪ في وقت العرض. قررت التمسك بـ 2.18 في الوقت الحالي. قد نفكر في تبديل الأطر إذا كان يتطلب إعادة بناء كبيرة.

@ Caglayan06 هل يمكنك تأكيد أنك تعمل مع علم الإنتاج؟ فقط تريد التأكد من أن الأرقام تفاح مقابل تفاح!

@ Caglayan06 - من غير المحتمل أن يكون هذا شيئًا منفردًا. قد لا يتطابق الاستنساخ الذي قدمهbarisnisanci مع ما مثال repobarisnisanci أعلاه يمثل سيناريوهات الاستخدام / مخرجات الملف الشخصي)؟

هل لديك أية تعليقات على آخر مشاركة لـ barisnisanci في هذا الموضوع؟
واجهتنا مشكلات أداء مماثلة بعد ترقية 2.18 إلى 3.16. كان لدينا 40٪ خسارة في الأداء. لقد خفضنا التصنيف إلى 3.12 ولكن تمكنا فقط من توفير 20٪ من تلك الخسارة ، ولا تزال أقل من 2.18 تقريبًا. تستغرق إعادة هيكلة الطريقة التي ذكرتها سابقًا وقتًا تقريبًا مثل تبديل الأطر. هل نتوقع أي إجراءات بشأن هذه المسألة؟

لقد قمنا مؤخرًا بالترقية إلى 3.16.8 ember ، وليس لدينا حالة اختبار أداء ولم نجد مشكلة أداء واضحة الآن.
ولكن أود أن أتطلع إلى حل مشكلات الأداء وإغلاقها في أقرب وقت.
>

PS ： المزيد من الذاكرة ووحدة المعالجة المركزية المستخدمة في ie11. في بعض الأحيان يتسبب في تحطم ie11.

@ Caglayan06 - من غير المحتمل أن يكون هذا شيئًا منفردًا. قد لا يتطابق الاستنساخ الذي قدمهbarisnisanci مع ما مثال repobarisnisanci أعلاه يمثل سيناريوهات الاستخدام / مخرجات الملف الشخصي)؟

مثال rwjbluebarisnisanci يعمل بنفس الطريقة التي يقول بها barisnisanci .

@ Caglayan06 هل يمكنك تأكيد أنك تعمل مع علم الإنتاج؟ فقط تريد التأكد من أن الأرقام تفاح مقابل تفاح!

scottmessinger نعم ، نحن نعمل مع علم الإنتاج. نتائجنا مشابهة لنتائج barisnisanci .

قمنا بتحسين هيكل الكود الخاص بنا. لقد عززت الأداء لكنها ما زالت ليست سريعة مثل إصدار 2.18 سبتمبر. إذا أجرينا هذه التغييرات في 2.18 ، فقد حصلنا على أفضل النتائج.

لا يمكننا إصلاح نظام الشفرة الخاص بنا لتغيير بنية التعليمات البرمجية 3.16 والميزات الجديدة. هذا مكلف للغاية بالنسبة لنا ، لأن مشروعنا ضخم. ربما تكون إعادة بناء المشروع بالكامل أكثر تكلفة من تغيير إطار العمل. هل سيتم اتخاذ أي إجراء بشأن هذه المشكلة؟

هل سيتم اتخاذ أي إجراء بشأن هذه المشكلة؟

نعم طبعا! كل ما نحتاجه هو إيجاد الوقت للتوصيف ومعرفة ما يجري. لكن هذا لا يحتاج حقًا إلى انتظار أي شخص ولكنك تبحث فيه 😸

مثال rwjbluebarisnisanci يعمل بنفس الطريقة التي يقول بها barisnisanci .

@ Caglayan06 - حسنًا ، هذا ليس ما طلبته حقًا. وأنا أعلم أن @ barisnisanci في أعمال سبيل المثال، أنا يطلب منك مراجعته / لمحة عليه / مقارنة خصائص الأداء إلى التطبيق الخاص بك ومعرفة ما إذا كان _way_ أن المثال يعمل (وأبطأ) مباريات طلبك.

@ Caglayan06 - حسنًا ، هذا ليس ما طلبته حقًا. وأنا أعلم أن @ barisnisanci في أعمال سبيل المثال، أنا يطلب منك مراجعته / لمحة عليه / مقارنة خصائص الأداء إلى التطبيق الخاص بك ومعرفة ما إذا كان _way_ أن المثال يعمل (وأبطأ) مباريات طلبك.

rwjblue لقد دمجت repobarisnisanci في تطبيقنا ، وقد أعطت نتائج مماثلة. عندما قمنا بتغيير الإصدار من 3.16 إلى 3.12 ، تم تعزيز أدائنا.
ولكن لا يزال غير سريع مثل الإصدار 2.18.

في تطبيقنا بعض الأمثلة:

كنتيجة ل:
حتى أننا قمنا بتحسين بنية الكود ، متوسط ​​عدد مرات العرض ؛
2.18 وقت العرض: 1x ثانية
3.16 وقت تقديم: 1.6x ثانية.
3.12 وقت العرض: 1.4x ثانية.

3.20 لديه ترقية VM ، لذلك أتساءل عما إذا كان ذلك سيساعد هنا

NullVoxPopuli لم يحالفه الحظ مع 3.20.0-beta.2 FP: 3.4 ثانية (نفس الشيء مع 3.18)

نظرًا لأن 3.12 تُظهر نتائج أفضل ، أعتقد أنه قد يتم تقديم المشكلة مع التتبع التلقائي. قد يكون رقم 18225 أيضًا ذا صلة بالنظر إلى انخفاض أداء التطبيق بالكامل في 3.12 من @ Caglayan06 -> 3.16 معايير.

جلالة الملك. أتساءل عن مقدار الجهد المبذول في الأشياء المتخلفة

بعض الأسئلة العامة:

• ما هي قيمة علامة الميزة الاختيارية للمراقب غير المتزامن؟
• هل التطبيق المعني يستخدم QPs؟
• هل تؤثر السرعة السلبية على كل الطرق أم بعضها فقط؟

بعض الأسئلة العامة:

• ما هي قيمة علامة الميزة الاختيارية للمراقب غير المتزامن؟
• هل التطبيق المعني يستخدم QPs؟
• هل تؤثر السرعة السلبية على كل الطرق أم بعضها فقط؟

تضمين التغريدة

1. عدم استخدام علامة المراقبين غير المتزامنين أعتقد أن الإعداد الافتراضي خطأ في 3.12. في 3.16 لا يُحدث الاختبار مع كليهما فرقًا كبيرًا.
2. تستخدم QPs على نطاق واسع في الطرق الرئيسية. ومع ذلك ، لوحظ انخفاض الأداء حتى بدون أي.
3. تتأثر جميع الطرق

أيضًا ، لا يستخدم مستودع المثال أيًا مما ورد أعلاه ولكنه لا يزال أبطأ في 3.X. قد تكون أوقات العرض قد زادت تدريجيًا في كل إصدار ثانوي ، لذا لا يمكننا تحديد المشكلة بدقة.

تظهر تقارير Tracerbench أن 2.18 إلى 3.18 تتراجع بنسبة 17٪ تقريبًا لهذا السيناريو ولكنها تتحسن أيضًا بدلاً من التراجع بنسبة 18٪ تقريبًا إذا تم التحويل إلى مكون بصيص.

2.18 إلى 3.18 لا توجد تغييرات أخرى
2.18 إلى 3.18 + مكونات أوكتان + لامع

لقد حصلت على شوكة خاصة بي من هذا حيث أضفت عداءًا آليًا لهذا ، وأعمل على تحسين العداء حتى نتمكن من تضييق نطاقه بسرعة حسب الإصدار / الالتزام للعثور على مكان حدوث الانحدار (الانحدارات). https://github.com/runspired/version-performance/runs/801596557

شكراً جزيلاً لـ runspired لإعداد تلك الاختبارات! الآن بعد أن أصبح لدينا إعدادًا قويًا لقياس الانحدار بشكل موثوق ، يمكننا التكرار نحو إصلاح هذه المشكلات.

لالسياق،krisselden TracerBench نموا كأداة خصيصا لاختبار الأداء بطريقة الشمولية، ولقد تم استخدامه لrefactors الرئيسية مثل هذه داخليا و تنفيذ الديكور و تتبع autotracking / المراجعة . في LinkedIn ، نستخدمه لاختبار تطبيقاتنا قبل كل ترقية لـ Ember ، ولم نشهد هذا المستوى من الانحدار.

ومع ذلك ، يمكن أن يكون بالتأكيد شيئًا فاتنا. في النهاية ، نحن نختبر تطبيقات محددة لها حالات استخدام وسلوكيات محددة. قد تكون هذه مشكلة لم نلاحظها لأن تطبيقات حالة الاختبار لدينا لم تستخدم الوظيفة التي تراجعت ، مثل runspired 's.

سنقوم بالبحث لمعرفة ماهية المشكلة بالضبط وإيجاد حل. الأهم من ذلك ، أن مستوى الانحدار هذا غير مقبول لـ _any_ API ، حتى لو نشهد تسريعًا مع Octane. إذا لم يتمكن المستخدمون من الترقية والتبديل بشكل تدريجي ، فلن نتسلق الجبل معًا.

ترقبوا المزيد من التحديثات ، وسنخبرك عندما نكتشف الأشياء!

شكراً جزيلاً لـ runspired على https://github.com/TracerBench/tracerbench-compare-action

أردت فقط تقديم تحديث سريع لهذا:

أجرينا اختبار TracerBench مشابهًا للاختبار الذي أعدتهrunspired مع emberobserver.com ، وهو أحد تطبيقات الاختبار المعتادة لدينا ، لمعرفة ما إذا كان هناك أي غليان للضفادع قد حدث (على سبيل المثال ، تغييرات صغيرة في الأداء لم تكن مهمة من الإصدار إلى الإصدار ، ولكن تلخيصه إلى تحول كبير). فيما يلي نتائج هذا الاختبار:

ember-Observer-2.18-3.18.pdf

يمكننا أن نرى من هذه النتائج أن هناك قفزتين محددتين إلى حد ما:

1. Ember 3.0 إلى Ember 3.1
2. Ember 3.16 إلى Ember 3.17

يرجع التراجع في 3.17 إلى ترقية Glimmer VM ، ونحن نركز حاليًا على تقليل ذلك نظرًا لأنه حديث إلى حد ما ومن المرجح أن يبدأ في التأثير على التطبيقات التي يتم تحديثها في دورة LTS قريبًا.

كان الانحدار في 3.1 معروفًا بالفعل في ذلك الوقت ، عند المناقشة مع الفريق الأساسي. كان سبب ذلك ، جزئيًا ، هو تمكين المكتسبات الأصلية واستخدام Object.defineProperty . تم اعتباره تراجعًا مقبولًا للسماح لإطار العمل بالمضي قدمًا مع ميزات المتصفح الأحدث.

بشكل عام ، يبدو أن السيناريو {{each}} الذي تم طرحه في بداية هذه المشكلة قد تراجع أكثر وبطرق مختلفة عن emberobserver.com. بمجرد أن نتعمق في الانحدار 3.17 ، سنركز على تحسين {{each}} لمعرفة ما يمكن تحسينه هناك بشكل عام.

هل لا تزال تذهب إلى المدرسة!

هل يمكننا الحصول على تحديث حول هذه المسألة؟ لقد مر حوالي شهرين.

نعم! لقد مر شهران طويلان ، لقد عملنا بجد لحل هذه المشكلة وفي مواصلة إعادة بناء مصانعنا في Glimmer VM ، والتي تراجعت بشكل جيد مع هذا.

كما ذكرت من قبل ، كنا نركز على مجموعتين منفصلتين من الإصلاحات:

1. معالجات إعادة البناء منخفضة المخاطر تهبط في الإصدار 3.20 LTS ، للأشخاص الذين يحاولون الترقية إلى LTS التالي
2. إعادة بناء المعامل على نطاق أكبر للهبوط على المستوى الرئيسي ، لتحسين الأداء على المدى الطويل

بالنسبة للمجموعة الأولى من الإصلاحات ، قمنا بإعادة هيكلة كمية مناسبة من كود Ember الكلاسيكي ، حيث كان الرمز هو الأكثر تأثراً. تمكنا من تقليل الخسارة الإجمالية للأداء من 3.16-3.20 وصولاً إلى مبالغ غير مهمة إحصائيًا بهذه الطريقة ، بناءً على الاختبار في تطبيقاتنا الداخلية في LinkedIn. لم تتح لي الفرصة لإجراء الاختبارات ضد Ember Observer لسوء الحظ ، لكنني أعتقد أنها ستكون نتيجة مماثلة لأنهم عادة ما يتتبعون بشكل وثيق معًا.

بالنسبة للمجموعة الثانية من الإصلاحات ، فقد وصلنا مؤخرًا نسبيًا لأن الكثير منها كان كبيرًا جدًا ، بما في ذلك:

• تحديث VM ليكون التتبع التلقائي بالكامل داخليًا ، والتخلص من العلامات الزائدة
• إعادة هيكلة الجهاز الظاهري لاستخدام فئة مرجعية أحادية الشكل ، بدلاً من العديد من التطبيقات التي تحتوي على الكثير من التعقيد
• إزالة وضع ترجمة AoT غير المستخدم

النتائج رائعة جدا!

results.pdf

يقارن هذا الإصدار الرئيسي الحالي لـ Ember بـ Ember 2.18 ، مع النسخ أعلاه منbarisnisanci. الآن ، كما ذكرنا سابقًا ، يعد هذا معيارًا لحالة استخدام محددة للغاية ، وهي أيضًا بسيطة للغاية. لم نشهد مثل هذا التحسن الهائل في أي من معايير تطبيقنا في العالم الحقيقي ، فقد كان أكثر تواضعًا بشكل عام. نأمل أن يساعد هذا barisnisanci وتطبيقات الآخرين ونحن بالتأكيد مهتمون بسماع رد منهم!

تم اختبار الريبو أعلاه مع الفرع الرئيسي من الجمرة. Still First Paint: (3035.7 مللي ثانية) تبدو أكبر من 2.18 (2752.3 مللي ثانية)

تم اختباره أيضًا على إنتاجنا بإصدارات مختلفة من ember. يبدو الفرع الرئيسي٪ 25 إلى 40٪ أبطأ من 3.12 على تطبيقنا. مع النتائج أدناه ، لا يمكننا ترقية العضو بدون إعادة بناء ديون كبيرة.

barisnisanci آسف يبدو أن هذا هو الحال! كما ذكرت سابقًا في هذا الموضوع ، سنحتاج إلى إعادة إنتاج هذه النتائج بطريقة سليمة إحصائيًا حتى نتمكن من تأكيد المشكلة و B. التكرار نحو التحسينات وإيجاد حل أفضل بشكل عام. أوصي إما بإضافة TracerBench إلى التطبيق الخاص بك حتى تتمكن من تشغيل هذه المعايير بنفسك ، أو إجراء نسخ آخر يوضح المشكلة الآن على master .