Redux потребление памяти [закрыто]

23

Среда Redux поддерживает парадигму неизменяемого состояния / чистой функции, которая способствует созданию нового состояния из предыдущего состояния с точки зрения текущего действия. Применимость этой парадигмы бесспорна.

Моя главная проблема заключается в том, что, поскольку редукторы Redux с готовностью возвращают новые новые состояния из предыдущих состояний для каждого вызванного действия, массовая утечка памяти (не путать с утечками памяти) станет обычным явлением во многих реальных приложениях. , Если учесть, что приложения Javascript обычно запускаются в браузере на устройствах среднего пользователя, которые также могут запускать несколько других приложений, специфичных для данного устройства, и еще несколько вкладок и окон браузера, необходимость сохранения памяти становится все более очевидной.

Кто-нибудь на самом деле сравнивал потребление памяти приложением Redux с традиционной архитектурой Flux? Если да, могут ли они поделиться своими выводами?

000
источник
4
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что он запрашивает произвольную информацию о профилировании памяти.
Были ли вы профилированного это?
Почему я должен профилировать это? Чтобы подтвердить очевидное? Разве это не здравый смысл, что порождение подобного объекта снова и снова влечет за собой серьезные накладные расходы с точки зрения использования памяти? Ответ @ Дана дает возможность минимизировать эти накладные расходы, и это пока лучший ответ.
000

Ответы:

30

Это действительная проблема. Хотя я не измерял использование памяти приложениями Redux, я думаю, что перед принятием решения использовать Redux (или любую другую платформу в этом отношении) вы должны создать стресс-тесты, которые эмулируют объемы данных, частоту изменений и интенсивность вычислений приложения, которое вы используете. собираются строить. Используйте эти стресс-тесты, прежде чем принимать технологические решения о том, работает ли неизменность в вашем конкретном случае.

Обратите внимание, что иногда люди путаются в Redux и считают, что при каждом действии дерево состояний должно быть глубоко клонировано. Это абсолютно не тот случай. Только части, которые изменились, должны изменить свои ссылки. Например, если действие вызывает изменение одного элемента в массиве, действительно, этот элемент и массив необходимо будет скопировать, однако все остальные элементы в массиве сохранят свои идентификаторы. Поскольку в большинстве случаев действия являются очень целенаправленными и затрагивают несколько ключей состояния, а Redux поощряет нормализацию данных, чтобы структуры данных не были глубоко вложенными, для типичных веб-приложений это гораздо меньше проблем, чем можно себе представить.

Вы также захотите изучить использование таких библиотек, как Immutable.js, которые эффективно реализуют неизменяемые списки и карты, используя внутреннее структурное совместное использование. Таким образом, изменение нескольких элементов в списке не требует большого количества копирования, поскольку внутренняя часть большей части памяти распределяется между различными версиями структуры данных.

Но, в конце концов, единственный способ сказать это - написать стресс-тесты, которые точно имитируют предполагаемое использование вашего приложения, и измерить эффективность для себя.

Дэн
источник
10
Не спешите переходить на Immutable.js. В нашем случае это становится серьезным занятием памяти. Immutable.js берет ваши (предположительно) аккуратные простые объекты и создает их в монстрах, жаждущих памяти. Посмотрите на этот пример: jsfiddle.net/sn70x2p6 После загрузки вкладка занимает 61 000 КБ памяти. После создания миллиона простых объектов это 211 000 КБ. Псих. Теперь нажмите «сделать неизменным» и посмотрите, что произойдет. Это переходит к более чем 1 ГБ памяти. Ваш опыт может отличаться, но не сильно.
Олав Коковкин