Ember.js: Kehilangan kinerja antara versi 2.X dan 3.X.

Setelah beberapa kali berjalan di Chrome 81 di komputer saya, saya mendapat:

2.18 waktu terbaik: 283ms
3.18 waktu terbaik: 471ms

Itu menjalankannya dengan DevTools ditutup.

Kemudian saya mengubah putaran 3,18 menjadi Ember Octane dengan:

• Menggunakan kelas asli untuk komponen & pengontrol.
• Menggunakan @tracked dan tidak menggunakan @computed .
• Mengonversi komponen t-r menjadi komponen khusus template karena tidak memerlukan kelas pendukung.
• Menggunakan sintaks kurung sudut saat menjalankan komponen.
• Menggunakan args bernama dan this. jika sesuai di template.

Setelah itu waktu terbaik yang saya dapat dari 3.18.1 adalah 276ms, jadi peningkatan yang berarti sejalan dengan angka 2.18.

Tes kinerja ini tidak terlalu ilmiah, dan saya belum menyelidiki perubahan mana yang paling penting dalam hal kinerja.

Membuat profil di twiddle cukup rawan kesalahan, dapatkah kita porting ke repo aplikasi ember-cli normal (menggunakan cabang untuk masing-masing dari dua versi) untuk dijadikan profil?

@rwjblue Saya mendapatkan hasil yang sama di aplikasi ember-cli biasa. Bisa dicoba disini

@ richard-viney Mungkin ada perbaikan untuk dipertimbangkan tetapi masalahnya adalah bahwa tidak ada kode yang tidak digunakan lagi yang digunakan di kedua versi dan mengalami penurunan kinerja tampaknya tidak dapat diterima.

• Menggunakan template-only-component dapat menyebabkan peningkatan kinerja, tetapi tr pasti membutuhkan kelas dukungan untuk menghitung beberapa gaya dalam. Contoh disederhanakan untuk menunjukkan masalah.
• Dengan semua refactoring Anda mendapatkan 2 persen (283ms -> 276ms) peningkatan kinerja dibandingkan 2,18. Pertimbangkan aplikasi 2.18 yang sudah ada yang ditingkatkan ke 3.X. Memfaktorkan ulang semua komponen hanya untuk mendapatkan peningkatan 2 persen itu jelas tidak memungkinkan.

@barisnisanci Setuju, saya tidak bermaksud menyarankan bahwa

Menarik untuk mengetahui rilis Ember mana yang memperkenalkan regresi kinerja dengan juga menguji versi LTS yang mengintervensi, yaitu 3.4, 3.8, 3.12, dan 3.16.

@barisnisanci Ember ember serve dijalankan dalam mode pengembangan secara default. Selama pengembangan, banyak perkakas tambahan diaktifkan yang dapat menurunkan kinerja secara serius. Kami biasanya tidak menganggap ini sebagai regresi atau masalah, kecuali itu cukup buruk untuk memengaruhi ergonomi pengembang. Jadi pertama-tama, saya akan memeriksa ulang apakah Anda menjalankan kedua versi dalam mode produksi.

Saya mengunduh contoh Anda dan menyajikan 2,8 dan 3,18 secara berdampingan dalam mode produksi. Apa yang saya temukan adalah sepertinya Anda mungkin benar, rata-rata waktu antara dua operasi helper (yang diukur di sini) tampak lebih besar di 3,18 daripada di 2,8. Itu berdasarkan saya mengambil beberapa sampel di laptop kerja saya tanpa banyak kontrol, jadi sulit untuk mengatakannya dengan pasti, tetapi jika dilihat secara langsung, ini bisa jadi sedikit perubahan.

Namun, melihat metrik lain yang lebih bermakna, saya tidak melihat perubahan. Secara khusus melihat waktu keseluruhan untuk merender konten, mereka terlihat hampir sama secara umum. Time to First Paint hampir sama, misalnya.

Penting untuk diingat bahwa kami memiliki banyak pekerjaan yang tersebar di banyak tempat, dan ketika kami membuat perubahan, terkadang pekerjaan itu berpindah-pindah tetapi tidak memengaruhi metrik _overall_. Inilah alasan kami menggunakan TracerBench untuk memeriksa perubahan kinerja, karena ini dirancang untuk mempertimbangkan keseluruhan fase render dan memperhitungkan semua perubahan pada tingkat _macro_, bukan pada tingkat _micro_, seperti pengaturan waktu antara pembantu yang berjalan.

Kami mungkin harus mencoba melakukan tes TracerBench segera dalam jangka waktu yang lebih lama, hanya untuk memverifikasi temuan ini dan untuk memastikan kami tidak tergelincir secara umum (kami biasanya menggunakannya untuk perubahan yang lebih kecil di mana kami mengharapkan potensi regresi). Kami juga harus mencoba menjalankannya secara berkala, sehingga kami dapat melihat garis tren.

@pzuraq Baru saja memperbarui repositori dengan rowsCount:300 dan perbedaan columnsCount:20 seharusnya lebih terlihat sekarang. Keduanya berjalan dengan --environment production

• 3.18 Cat Pertama: 3489 ms
  
• 2.18 Cat Pertama: 2814 ms
  

Juga perhatikan bahwa JS Heap tidak pernah dirilis di 3.18 tapi mungkin sedikit nasib buruk di GC.

Saya dapat menambahkan style binding, injeksi layanan, komputasi yang lebih berat pada komponen daripada menambah jumlah, namun hal tersebut mungkin membayangi masalah yang mendasarinya.

Seperti yang Anda sebutkan, metrik keseluruhan jauh lebih penting daripada perubahan kecil. Namun perbedaan kecil menambah penurunan kinerja yang besar dalam kasus kami. Waktu render awal aplikasi komersial kami meningkat dari 15 detik menjadi 20 detik setelah meningkatkan versi ke 3,18. Mudah-mudahan Anda akan mempertimbangkan regresi dalam persentase daripada sedikit perubahan milidetik.

Perusahaan kami mengalami masalah ini. Kami memperbarui versi ember dari 2.18 menjadi 3.16. maka waktu render kami menjadi lebih dari '50' persen. Saat kami menggunakan struktur yang rumit, perbedaan antara waktu render menjadi lebih jelas daripada sedikit perubahan milidetik. Adakah pembaruan tentang masalah ini? Kami memiliki tolok ukur yang menunjukkan peningkatan% 50 dalam waktu render. Memutuskan untuk mempertahankan 2.18 untuk saat ini. Kami dapat mempertimbangkan untuk mengganti kerangka kerja jika itu akan membutuhkan refaktor besar.

@ Caglayan06 Bisakah Anda mengonfirmasi bahwa Anda berlari dengan bendera produksi? Hanya ingin memastikan angkanya adalah apel untuk apel!

@ Caglayan06 - Ini tidak mungkin bahwa ini adalah satu hal. Reproduksi yang diberikan @barisnisanci mungkin tidak cocok dengan yang ditampilkan profil aplikasi Anda. Dapatkah Anda memberikan reproduksi masalah umum di aplikasi Anda (atau mengonfirmasi bahwa contoh repo @barisnisanci dari atas mewakili skenario penggunaan / keluaran profil Anda)?

Apakah Anda memiliki komentar untuk posting terbaru @barisnisanci di utas ini?
Kami mengalami masalah kinerja yang serupa setelah meningkatkan versi 2.18 ke 3.16. Kami mengalami 40% kehilangan kinerja. Kami menurunkan versi ke 3.12 tetapi hanya berhasil menghemat 20% dari kerugian itu, masih tidak sebagus 2.18. Memfaktorkan ulang cara yang Anda sebutkan sebelumnya membutuhkan waktu yang hampir sama dengan mengganti kerangka kerja. Haruskah kami mengharapkan tindakan apa pun terkait masalah ini?

baru-baru ini kami meningkatkan ke ember 3.16.8, kami tidak memiliki kasus uji kinerja dan tidak menemukan masalah kinerja yang jelas sekarang.
tetapi saya ingin segera menyelesaikan & menutup masalah kinerja.
>

PS: lebih banyak memori dan cpu yang digunakan di ie11. terkadang itu menyebabkan crash IE11.

@ Caglayan06 - Ini tidak mungkin bahwa ini adalah satu hal. Reproduksi yang diberikan @barisnisanci mungkin tidak cocok dengan yang ditampilkan profil aplikasi Anda. Dapatkah Anda memberikan reproduksi masalah umum di aplikasi Anda (atau mengonfirmasi bahwa contoh repo @barisnisanci dari atas mewakili skenario penggunaan / keluaran profil Anda)?

Contoh @rwjblue @barisnisanci bekerja sama bagi saya seperti yang dikatakan

@ Caglayan06 Bisakah Anda mengonfirmasi bahwa Anda berlari dengan bendera produksi? Hanya ingin memastikan angkanya adalah apel untuk apel!

@scottmessinger ya, kami menjalankan dengan flag produksi. Hasil kami serupa dengan hasil @barisnisanci .

Kami meningkatkan struktur kode kami. Ini meningkatkan kinerja Tapi tetap saja tidak secepat versi ember 2.18. Jika kami membuat perubahan itu di 2.18, kami mengambil hasil terbaik.

Kami tidak dapat merombak sistem kode kami untuk mengubah sintaks kode 3.16 dan fitur baru. Ini terlalu mahal bagi kami, karena proyek kami sangat besar. Mungkin refactoring semua proyek lebih mahal daripada mengubah kerangka kerja. Akankah tindakan diambil untuk masalah ini?

Akankah tindakan diambil untuk masalah ini?

Ya tentu saja! Kami hanya perlu mencari waktu untuk membuat profil dan mencari tahu apa yang sedang terjadi. Tapi itu tidak perlu menunggu siapa pun kecuali Anda menggali lebih dalam 😸

Contoh @rwjblue @barisnisanci bekerja sama bagi saya seperti yang dikatakan

@ Caglayan06 - Hmm, bukan itu yang saya tanyakan. Saya tahu bahwa contoh @ barisnisanci berfungsi, saya meminta Anda untuk meninjaunya / membuat profil / membandingkan karakteristik kinerja dengan aplikasi Anda dan melihat apakah _way_ bahwa contoh tersebut berfungsi (dan lebih lambat) cocok dengan aplikasi

@ Caglayan06 - Hmm, bukan itu yang saya tanyakan. Saya tahu bahwa contoh @ barisnisanci berfungsi, saya meminta Anda untuk meninjaunya / membuat profil / membandingkan karakteristik kinerja dengan aplikasi Anda dan melihat apakah _way_ bahwa contoh tersebut berfungsi (dan lebih lambat) cocok dengan aplikasi

@rwjblue saya mengintegrasikan repo @barisnisanci ke aplikasi kita, hasilnya serupa. Saat kami mengubah versi dari 3.16 menjadi 3.12, kinerja kami meningkat.
Tapi masih belum secepat versi 2.18.

Dalam aplikasi kami untuk beberapa contoh:

Hasil dari:
Bahkan kami meningkatkan struktur kode, total waktu render rata-rata;
2.18 waktu render: 1x detik
3.16 waktu render: 1,6x dtk.
3.12 waktu render: 1,4x dtk.

3.20 memiliki peningkatan VM, jadi saya ingin tahu apakah itu akan membantu di sini

@NullVoxPopuli tidak beruntung dengan 3.20.0-beta.2 FP: 3.4 detik (sama dengan 3.18)

Karena 3.12 menunjukkan hasil yang lebih baik, saya pikir masalahnya mungkin disebabkan oleh pelacakan otomatis. Juga # 18225 mungkin terkait dengan mempertimbangkan penurunan kinerja aplikasi secara keseluruhan di 3,12 @ Caglayan06 -> 3,16.

Hm. Saya bertanya-tanya berapa banyak overhead hal compat mundur

Beberapa pertanyaan umum:

• Berapakah nilai untuk tanda fitur opsional pengamat asinkron?
• Apakah aplikasi yang dimaksud menggunakan QP?
• Apakah kecepatan negatif memengaruhi semua rute atau hanya beberapa?

Beberapa pertanyaan umum:

• Berapakah nilai untuk tanda fitur opsional pengamat asinkron?
• Apakah aplikasi yang dimaksud menggunakan QP?
• Apakah kecepatan negatif memengaruhi semua rute atau hanya beberapa?

@tokopedia

1. Tidak menggunakan flag pengamat async. Saya pikir defaultnya salah pada 3.12. Pada 3.16 Diuji dengan keduanya tidak membuat banyak perbedaan.
2. QP banyak digunakan di rute-rute utama. Namun penurunan kinerja diamati bahkan tanpa ada.
3. Semua rute terpengaruh

Juga contoh repositori tidak menggunakan salah satu dari yang di atas tetapi masih lebih lambat di 3.X. Waktu perenderan mungkin telah meningkat secara bertahap di setiap versi kecil sehingga kami tidak dapat menentukan masalah yang sebenarnya.

Laporan Tracerbench menunjukkan bahwa 2,18 hingga 3,18 mengalami kemunduran ~ 17% untuk skenario ini tetapi juga meningkat alih-alih mengalami kemunduran sebesar ~ 18% jika konversi ke komponen kilau dilakukan.

2.18 hingga 3.18 Tidak ada Perubahan lain
2.18 Sampai 3.18 + Oktan + Komponen Kilau

Saya punya garpu sendiri untuk ini di mana saya telah menambahkan pelari otomatis untuk ini, dan saya bekerja untuk meningkatkan pelari sehingga kami dapat dengan cepat mempersempit berdasarkan versi / komit untuk menemukan di mana regresi terjadi. https://github.com/runspired/version-performance/runs/801596557

Terima kasih banyak kepada @runspired karena telah menyiapkan pengujian tersebut! Sekarang setelah kami memiliki penyiapan yang solid untuk mengukur regresi secara andal, kami dapat mengulangi untuk memperbaiki masalah ini.

Untuk konteks, @krisselden mengembangkan TracerBench sebagai alat khusus untuk menguji kinerja dengan cara yang menyeluruh, dan kami telah menggunakannya untuk refaktor utama secara internal seperti penerapan dekorator dan pelacakan pelacakan otomatis / revisi . Di LinkedIn kami menggunakannya untuk menguji aplikasi kami sebelum setiap peningkatan Ember, dan kami belum melihat tingkat regresi ini.

Namun, itu pasti bisa menjadi sesuatu yang kami lewatkan. Pada akhirnya kami menguji aplikasi tertentu, yang memiliki kasus penggunaan dan perilaku tertentu. Ini bisa menjadi masalah yang tidak kami tangkap karena aplikasi kasus pengujian kami tidak menggunakan fungsionalitas yang mundur, seperti reproduksi @barisnisanci . Mungkin juga jika kami memperbaiki masalah dalam reproduksi itu, kami mungkin tidak memperbaiki yang lain, jadi jika Anda mengalami regresi, kami pasti akan menghargai reproduksi untuk kasus penggunaan Anda. Kami akan berupaya membuat penyiapan TracerBench lebih mudah digunakan sehingga Anda dapat mengujinya secara lokal dan mengirimkan repro seperti @runspired 's.

Kami akan menggali untuk mencari tahu apa masalah sebenarnya dan mencari solusinya. Yang terpenting, tingkat regresi ini tidak dapat diterima untuk _any_ API, meskipun kami melihat kecepatan dengan Oktan. Jika pengguna tidak dapat meningkatkan dan beralih secara bertahap, maka kita tidak semua mendaki gunung bersama.

Nantikan pembaruan lebih lanjut, kami akan memberi tahu Anda saat kami memikirkannya!

Terima kasih banyak kepada @runspired atas kerennya yang jahat https://github.com/TracerBench/tracerbench-compare-action

Hanya ingin memberikan pembaruan cepat tentang ini:

Kami menjalankan pengujian TracerBench yang serupa dengan yang @runspired siapkan dengan emberobserver.com , yang merupakan salah satu aplikasi pengujian kami yang biasa, untuk melihat apakah ada kodok mendidih yang telah terjadi (misalnya perubahan kinerja kecil yang tidak signifikan dari versi ke versi, tetapi diringkas menjadi pergeseran besar). Berikut hasil dari tes tersebut:

ember-pengamat-2.18-3.18.pdf

Kita dapat melihat dari hasil ini bahwa ada dua lompatan yang cukup pasti:

1. Ember 3.0 hingga Ember 3.1
2. Ember 3.16 sampai Ember 3.17

Regresi di 3.17 disebabkan oleh peningkatan VM Glimmer, dan kami saat ini berfokus untuk menguranginya karena ini cukup baru dan kemungkinan akan mulai memengaruhi aplikasi yang memperbarui pada siklus LTS segera.

Regresi di 3.1 sebenarnya diketahui pada saat itu, setelah berdiskusi dengan tim inti. Hal ini disebabkan, sebagian, dengan mengaktifkan getter asli dan menggunakan Object.defineProperty . Itu dianggap sebagai regresi yang dapat diterima untuk memungkinkan framework bergerak maju dengan fitur browser yang lebih baru.

Secara umum, skenario {{each}} yang muncul di awal terbitan ini tampaknya telah mengalami kemunduran lebih banyak dan dengan cara yang berbeda dari emberobserver.com. Setelah kami menggali regresi 3.17, kami akan fokus pada mengoptimalkan {{each}} untuk melihat apa yang dapat ditingkatkan di sana secara umum.

Terima kasih semuanya atas kesabaran Anda!

Bisakah kami mendapatkan pembaruan tentang masalah ini? Sudah sekitar dua bulan.

Iya! Sudah dua bulan yang panjang, kami telah bekerja keras untuk masalah ini dan melanjutkan refactors kami di Glimmer VM, yang sangat cocok dengan ini.

Seperti yang saya sebutkan sebelumnya, kami berfokus pada dua set perbaikan terpisah:

1. Refaktor berisiko rendah akan mendarat di rilis 3,20 LTS, untuk orang-orang yang mencoba meningkatkan ke LTS berikutnya
2. Refaktor berskala lebih besar untuk mendarat di master, untuk meningkatkan kinerja dalam jangka panjang

Untuk set perbaikan pertama, kami memfaktorkan ulang sejumlah kode Ember klasik yang layak, karena kode itulah yang paling terpengaruh. Dengan cara ini, kami dapat mengurangi penurunan kinerja secara keseluruhan dari 3,16-3,20 menjadi jumlah yang tidak signifikan secara statistik dengan cara ini, berdasarkan pengujian di aplikasi internal kami di LinkedIn. Sayangnya saya belum memiliki kesempatan untuk menjalankan tes terhadap Ember Observer, tapi saya pikir itu akan menjadi hasil yang serupa karena biasanya mereka melacak cukup dekat.

Untuk set perbaikan kedua, kami relatif baru-baru ini mendapatkan ini karena banyak di antaranya sangat besar, termasuk:

• Memperbarui VM menjadi sepenuhnya berbasis pelacakan otomatis secara internal, menghilangkan tag berlebih
• Memfaktorkan ulang VM untuk menggunakan kelas referensi monomorfik tunggal, bukan banyak implementasi dengan banyak kerumitan
• Menghapus mode kompilasi AoT yang tidak digunakan

Hasilnya lumayan bagus!

results.pdf

Ini membandingkan master Ember saat ini dengan Ember 2.18, dengan reproduksi di atas dari @barisnisanci. Sekarang, seperti yang disebutkan sebelumnya, ini adalah tolok ukur untuk kasus penggunaan yang sangat spesifik, yang juga terlalu sederhana. Kami _tidak_ melihat peningkatan dramatis dalam tolok ukur aplikasi dunia nyata kami, itu jauh lebih sederhana secara keseluruhan. Mudah-mudahan ini akan membantu @barisnisanci dan aplikasi lain dan kami sangat tertarik untuk mendengar kabar dari mereka!

Repo teruji di atas dengan cabang master ember. Still First Paint: (3035,7 ms) tampak lebih besar dari 2,18 (2752,3 ms)

Juga diuji pada produksi kami dengan versi ember yang berbeda. Cabang master tampaknya% 25 hingga% 40 lebih lambat dari 3.12 di aplikasi kita. Dengan hasil di bawah ini kita tidak bisa mengupgrade ember tanpa refactoring besar-besaran.

@barisnisanci Maaf sepertinya itu masalahnya! Seperti yang saya sebutkan sebelumnya di utas ini, kami akan perlu mereproduksi hasil ini dengan cara yang secara statistik masuk akal agar dapat A. mengkonfirmasi masalah dan B. mengulangi ke arah perbaikan dan solusi yang lebih baik secara keseluruhan. Saya sarankan untuk menambahkan TracerBench ke aplikasi Anda sehingga Anda dapat menjalankan tolok ukur ini sendiri, atau membuat reproduksi lain yang mendemonstrasikan masalah ini sekarang pada master .