Konsumsi memori redux [tertutup]

Kerangka kerja Redux mendukung negara / paradigma fungsi murni, yang mempromosikan penciptaan negara baru dari negara sebelumnya dalam hal tindakan saat ini. Penerapan paradigma ini tidak dapat dielakkan.

Kekhawatiran utama saya adalah bahwa, ketika Redux mengurangi dengan penuh semangat mengembalikan negara baru dari negara sebelumnya untuk setiap tindakan yang dilakukan, pengurasan memori besar-besaran (jangan dikacaukan dengan kebocoran memori) akan menjadi kejadian umum di banyak aplikasi dunia nyata. . Ketika mempertimbangkan bahwa aplikasi Javascript biasanya berjalan di browser di perangkat rata-rata pengguna yang juga bisa menjalankan beberapa aplikasi spesifik perangkat lainnya dan beberapa tab browser dan jendela lebih, kebutuhan untuk menghemat memori menjadi semakin jelas.

Adakah yang benar-benar membandingkan konsumsi memori aplikasi Redux dengan arsitektur Flux tradisional? Jika demikian, dapatkah mereka membagikan temuan mereka?

Ini adalah kekhawatiran yang valid. Meskipun saya belum mengukur penggunaan memori aplikasi Redux, saya pikir sebelum berkomitmen untuk menggunakan Redux (atau kerangka kerja lainnya), Anda harus membuat tes stres yang meniru jumlah data, mengubah frekuensi, dan intensitas komputasi aplikasi yang Anda gunakan. akan membangun. Gunakan tes stres ini sebelum membuat keputusan teknologi tentang apakah mengadopsi ketidakberdayaan bekerja dalam kasus khusus Anda.

Perhatikan bahwa kadang-kadang orang bingung tentang Redux dan menganggap bahwa pada setiap tindakan, pohon negara harus dikloning secara mendalam. Ini sama sekali tidak terjadi. Hanya bagian yang diubah yang perlu diubah referensi mereka. Misalnya, jika suatu tindakan menyebabkan perubahan ke satu item dalam array, tentu saja, item itu dan array perlu disalin, namun , semua elemen lain dalam array akan menyimpan identitasnya. Karena sebagian besar waktu tindakan sangat bertarget dan memengaruhi beberapa kunci negara, dan karena Redux mendorong normalisasi data sehingga struktur data tidak bersarang secara mendalam, ini jauh lebih sedikit masalah bagi webapps tipikal daripada yang dibayangkan orang.

Anda juga ingin menjelajah menggunakan pustaka seperti Immutable.js yang mengimplementasikan daftar dan peta yang tidak dapat diubah secara efisien dengan menggunakan pembagian struktural secara internal. Dengan cara ini, mengubah beberapa item dalam daftar tidak melibatkan banyak penyalinan karena secara internal sebagian besar memori dibagikan di antara versi struktur data yang berbeda.

Namun pada akhirnya, satu-satunya cara untuk mengetahuinya adalah dengan menulis tes stres yang dengan ketat meniru penggunaan aplikasi yang dimaksudkan, dan mengukur efisiensi untuk diri sendiri.