Zużycie pamięci redux [zamknięte]

23

Struktura Redux faworyzuje paradygmat stanu niezmiennego / funkcji czystej, który promuje tworzenie nowego stanu z poprzedniego stanu pod względem bieżącej akcji. Zastosowanie tego paradygmatu jest niepodważalne.

Mój główny problem dotyczy tego, że ponieważ reduktory Redux chętnie zwracają nowe, nowe stany z poprzednich stanów dla każdej wywoływanej akcji, masowy drenaż pamięci (nie mylić z przeciekami pamięci) stałby się częstym zjawiskiem w wielu rzeczywistych aplikacjach . Biorąc pod uwagę, że aplikacje Javascript zwykle działają w przeglądarce na urządzeniach przeciętnego użytkownika, które mogą również uruchamiać kilka innych aplikacji specyficznych dla urządzenia oraz kilka innych kart i okien przeglądarki, potrzeba oszczędzania pamięci staje się coraz bardziej oczywista.

Czy ktoś faktycznie porównał zużycie pamięci przez aplikację Redux do tradycyjnej architektury Flux? Jeśli tak, czy mogliby podzielić się swoimi odkryciami?

000
źródło
4
Głosuję za zamknięciem tego pytania jako nie na temat, ponieważ wymaga ono podania dowolnych informacji profilowania pamięci.
Czy jesteś profilowane go?
Dlaczego powinienem to profilować? Aby potwierdzić to, co oczywiste? Czy nie jest rozsądne, że odradzanie podobnego obiektu wielokrotnie wiąże się z poważnymi kosztami związanymi z użyciem pamięci? Odpowiedź @ Dana stanowi sposób na zminimalizowanie tego narzutu i jest to najlepsza jak dotąd odpowiedź.
000

Odpowiedzi:

30

To jest ważny problem. Chociaż nie mierzyłem wykorzystania pamięci przez aplikacje Redux, myślę, że przed podjęciem korzystania z Redux (lub jakiegokolwiek innego frameworka w tej sprawie) powinieneś utworzyć testy warunków skrajnych, które emulują ilości danych, częstotliwość zmian i intensywność obliczeń aplikacji, którą ty zamierzają budować. Użyj tych testów warunków skrajnych przed podjęciem technologicznych decyzji dotyczących tego, czy przyjęcie niezmienności działa w twoim konkretnym przypadku.

Zauważ, że czasami ludzie mylą się z Redux i zakładają, że przy każdej akcji drzewo stanu musi być głęboko sklonowane. Absolutnie tak nie jest. Tylko zmienione części muszą zmienić swoje odniesienia. Na przykład, jeśli akcja spowoduje zmianę jednego elementu w tablicy, ten element i tablica będą musiały zostać skopiowane, jednak wszystkie inne elementy w tablicy zachowają swoją tożsamość. Ponieważ w większości przypadków akcje są bardzo ukierunkowane i wpływają na kilka kluczy stanu, a ponieważ Redux zachęca do normalizacji danych, aby struktury danych nie były głęboko zagnieżdżone, jest to o wiele mniej problem dla typowych aplikacji internetowych, niż można sobie wyobrazić.

Będziesz także chciał eksplorować za pomocą bibliotek takich jak Immutable.js, które skutecznie implementują niezmienne listy i mapy dzięki wewnętrznemu współużytkowaniu strukturalnemu. W ten sposób zmiana kilku pozycji na liście nie wymaga tak dużego kopiowania, ponieważ wewnętrznie większość pamięci jest dzielona między różne wersje struktury danych.

Ale w końcu jedynym sposobem, aby powiedzieć, jest napisanie testów warunków skrajnych, które ściśle naśladują zamierzone użycie aplikacji i zmierzą wydajność dla siebie.

Dan
źródło
10
Nie bądź taki szybki, aby przejść do Immutable.js. W naszym przypadku staje się to poważnym wyzwaniem pamięci. Immutable.js zabiera (prawdopodobnie) czyste, proste obiekty i tworzy z nich instancję spragnionych pamięci. Spójrz na ten przykład: jsfiddle.net/sn70x2p6 Po załadowaniu karta zajmuje 61 000 KB pamięci. Po zrobieniu miliona zwykłych obiektów ma 211 000 KB. Zwariowany. Teraz kliknij „uczyń niezmienną” i zobacz, co się stanie. Skacze do ponad 1 GB pamięci. Doświadczenie może się różnić, ale niewiele.
Olav Kokovkin