Consumo de memória Redux [fechado]


23

A estrutura Redux favorece o paradigma imutável de estado / função pura, que promove a criação de um novo estado a partir do estado anterior em termos da ação atual. A aplicabilidade desse paradigma é indubitável.

Uma grande preocupação minha é que, à medida que os redutores do Redux retornam ansiosamente novos estados de estados anteriores para cada ação invocada, um grande consumo de memória (que não deve ser confundido com vazamentos de memória) se tornaria uma ocorrência comum em muitas aplicações do mundo real . Ao considerar que os aplicativos Javascript normalmente são executados em um navegador nos dispositivos de um usuário comum, que também pode estar executando vários outros aplicativos específicos do dispositivo e várias outras guias e janelas do navegador, a necessidade de economizar memória se torna cada vez mais evidente.

Alguém já comparou o consumo de memória de um aplicativo Redux à arquitetura tradicional do Flux? Em caso afirmativo, eles poderiam compartilhar suas descobertas?


4
Estou votando para encerrar esta questão como off-topic, porque ela está solicitando informações arbitrárias de criação de perfil de memória.

que você perfilado-lo?

Por que devo criar um perfil? Para confirmar o óbvio? Não é senso comum que a geração repetida de um objeto semelhante acarrete uma sobrecarga séria em termos de uso de memória? A resposta de @ Dan fornece uma maneira de minimizar essa sobrecarga e essa é a melhor resposta até agora.
000 000

Respostas:


30

Esta é uma preocupação válida. Embora eu não tenha medido o uso de memória dos aplicativos Redux, acho que antes de se comprometer a usar o Redux (ou qualquer outra estrutura), você deve criar testes de estresse que simulem as quantidades de dados, alterem a frequência e a intensidade de computação do aplicativo vão construir. Use esses testes de estresse antes de tomar decisões tecnológicas sobre se a adoção da imutabilidade funciona no seu caso específico.

Observe que às vezes as pessoas ficam confusas sobre o Redux e assumem que, a cada ação, a árvore de estados precisa ser clonada profundamente. Este não é absolutamente o caso. Somente as partes que foram alteradas precisam alterar suas referências. Por exemplo, se uma ação causar uma alteração em um item de uma matriz, esse item e a matriz precisarão ser copiados; no entanto , todos os outros elementos da matriz manterão suas identidades. Como na maioria das vezes as ações são muito direcionadas e afetam algumas chaves de estado, e porque o Redux incentiva a normalização de dados para que as estruturas de dados não sejam profundamente aninhadas, isso é muito menos um problema para aplicativos da Web típicos do que se poderia imaginar.

Você também desejará explorar o uso de bibliotecas como o Immutable.js, que implementam listas e mapas imutáveis ​​de forma eficiente, usando o compartilhamento estrutural internamente. Dessa forma, alterar alguns itens de uma lista não envolve muita cópia, porque internamente a maior parte da memória está sendo compartilhada entre diferentes versões da estrutura de dados.

Mas, no final, a única maneira de saber é escrever os testes de estresse que simulam de perto o uso pretendido do seu aplicativo e medir a eficiência por si mesmo.


10
Não seja tão rápido em pular para Immutable.js. Está se tornando um sério problema de memória no nosso caso. Immutable.js pega seus objetos simples (presumivelmente) e os instancia em monstros famintos de memória. Dê uma olhada neste exemplo: jsfiddle.net/sn70x2p6 Após o carregamento, a guia ocupa 61.000 KB de memória. Depois de criar um milhão de objetos simples, são 211.000 KB. Louco. Agora clique em "tornar imutável" e veja o que acontece. Salta para mais de 1 GB de memória. Sua experiência pode ser diferente, mas não muito.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.