2016-11-05 6 views
2

Мой WebSocket получает «много» данных в коротких очередей, скажем, до 1000 объектов в 1-2s и для каждого я должен сделать это (добавить в хранилище): dispatch({ type: NEW, payload })Redux низкая производительность

а также фактический редуктор (с использованием неизменность помощника FBS):

case NEW: 
    return update(state, { 
    data: { 
     [action.payload.tree.name]: 
    { $push: [action.payload.name] }, 
    }, 
    }); 

Добавление 10 элементов одновременно работает отлично, 100 займет несколько секунд и 1000 довольно много перегруженных мой хром, работающих на последнем оборудовании.

Я также пытаюсь понять, почему при добавлении 100 элементов, например, он не перерисовывает страницу и не отображает каждую, поскольку она добавляется для хранения ... но вместо этого ожидают, пока не добавятся все, что попало в «пакет».

ответ

2

Рассмотрите возможность дозирования обновлений перед удалением диспетчера и измените действие, чтобы принять консолидированные массивы обновлений, а не отдельные обновления.

+0

Не могли бы вы предложить что-то, чтобы оптимизировать или избежать копирования больших объектов? У меня есть объект (карта «id => объект») с ключами 10k (историческая диаграмма), и на очень последнем этапе он очень медленный - редуктор. Другие части (даже сортировка и объединение данных из пакетных запросов API) оптимизируются и выполняются как микротовары (через setTimeout), но я действительно не знаю, что делать с назначением объектов ... – AlkH

+0

Нашел обсуждение с некоторыми возможными решениями: https: //github.com/reactjs/redux/issues/606 – AlkH

+1

Как вы определили узкое место как редуктор? Могут ли быть обновления DOM, которые происходят после обновления вашего магазина? Если обновления DOM являются ключевыми, просмотрите оконный рендеринг, где обновляются только элементы в окне просмотра. Если это действительно в редукторе, ваши данные действительно должны жить в магазине или могут оставаться в локальном состоянии/реквизитах и ​​т. Д.? – squall3d

Смежные вопросы