GWT FlexTable производительность и оптимизация

Question

Я работаю над проектом GWT, где мы используем FlexTable для отображения некоторых данных.Я знаю, что мы, вероятно, должны использовать CellTable , поскольку он имеет лучшую производительность, но FlexTable легче стилизовать (стилизовать определенные ячейки) и облегчает обновление определенной ячейки.

Для получения обновленийдля таблицы мы используем WebSockets.Проблема, с которой мы сталкиваемся сейчас, заключается в высокой загрузке процессора, когда через WebSockets происходит более 100 обновлений в секунду.Каждое сообщение от соединения WebSocket содержит обновления для нескольких ячеек в таблице.Таким образом, на практике в FlexTable должно отображаться более 100 обновлений в секунду.Загрузка процессора на моем 3GHz i5 с 4 ГБ оперативной памяти составляет около 50%.Если я отключу фактическую визуализацию данных (закомментируйте вызовы метода setText ()), тогда загрузка процессора снизится до 5-10%.Так что я знаю, что узкие места - это обновления DOM, а не другие части кода.

Было бы лучше

1. использовать Grid вместо
2. переключиться на CellTable(но как тогда выполнять обновления отдельных ячеек)?
3. использовать JS / JSNI для работы с DOM вместо FlexTable setText ()

Существуют ли более эффективные способы реализации таблиц и повышения производительности?

Я пытался гуглить, если у кого-то были похожие проблемы с FlexTable, но нашел только общее мнение, что он просто медленный, ничего конкретного.У нас есть прототип приложения, выполненный исключительно на JavaScript, и при тех же 100 обновлениях в секунду загрузка процессора составляет около 15%

Обновление
Эффект отбрасывания css, который мы использовали для обозначения изменения в ячейкезначение уменьшило загрузку процессора на ~ 10%.Так что, похоже, DOM - не единственная проблема.

Answer 1

С CellTable вы должны повторно визуализировать всю таблицу, чтобы обновить одну ячейку.Тем не менее, такое обновление будет одним обновлением DOM.С помощью FlexTable, даже если вы соберете все свои обновления вместе, вы будете выполнять кучу отдельных манипуляций с DOM.Таким образом, даже если использование CellTable может показаться неэффективным, поскольку вы обновляете некоторые ячейки избыточно, переключение может все же стоить того. Особенно в случае, когда вы обновляете количество ячеек, близких к общему количеству ячеек: пакетируйте 100 обновлений вместе и делайте их все сразу для одной записи DOM.

Iиметь приложение с CellTable размером 30x100.Он имеет произвольные стили для произвольных ячеек, каждая ячейка имеет сложное содержимое (<img>, немного <div> с и немного текста), и иногда мне нужно обновить одну ячейку.Перерисовка всего этого незаметна (по моему человеческому восприятию) на моем MacBook Pro в режиме разработки.

Если вы хотите живые обновления (например, 100 обновлений в секунду, как они происходят), то я думаю, что вы можете захотеть другоеПлатформа.Даже ваш монитор не обновляется 100 раз в секунду.

Answer 2

Вы можете использовать cellTable.redrawRow(index);, что быстрее для больших таблиц.
Хорошо, что индекс строки задается FieldUpdater.

Answer 3

В качестве альтернативы (или в дополнение к, в зависимости от того, какие результаты вы получаете) всему вышеперечисленному, я хотел бы изучить использование некоторых методов планировщика.Особенно Scheduler.get (). ScheduleIncremental () и делать обновления в пакетах, скажем, по 10 за раз.Это позволит браузеру обрабатывать другие события между обновлениями и должно положительно влиять на использование процессора.

CellTable вам здесь вообще не поможет, потому что вы не можете обновить отдельные ячейки.Таким образом, в качестве альтернативы он оставляет вам только Grid и вручную управляет TableElement.