Как стать автором
Обновить

JavaScript. Как сделать невероятно быстрый многопоточный Data Grid на 1 000 000 строк. Часть 2/2: работа с потоками

Уровень сложностиСредний
Время на прочтение3 мин
Количество просмотров5.4K
Всего голосов 16: ↑16 и ↓0+19
Комментарии18

Комментарии 18

Какая разница в производительности между двумя потоками с асинхронным поиском и одним потоком, стоит ли игра свеч? Дублирование больших данных выглядит как сомнительный подход, не проще ли использовать IndexedDB для этого?

Какая разница в производительности между двумя потоками с асинхронным поиском и одним потоком, стоит ли игра свеч?

👍 - это ключевой вопрос.

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

Хороший вопрос.

По моим экспериментам в отдельном потоке есть смысл. Если не выносить, UI зависает.

IndexDB не пробовал. Подозреваю что: или оно работает в этом же потоке, и тогда UI будет зависать. Или так же медленно передает данные как и обмен между потоками.

IndexedDB инициализировать долго.

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

Пробовал. С отдельным потоком лучше получилось.

Миллион строк обидно было бы потерять при перезагрузке страницы. Кроме того, этот миллион можно грузить лениво. Поэтому оптимально грузить данные частями и класть их в indexddb, на него вешать поисковой индекс и лениво выгребать данные из него, искользуя курсор.

Надо пробовать. Возможно indexdb не будет лениво отдавать данные со скоростью скрола.

Интересно, кому понадобится выводить в DOM и потом работать с лямом строк?

Лям строк - это, скорее всего, JSON, а DOMe, скорее всего, показывается "текущее окно" из 100 строк.

В DOM показывается меньше 100 строк. В DOM только строки которые на экран поместились.

Подробнее в первой части https://habr.com/ru/articles/862272/

Почему нельзя прервать процесс поиска через AbortController?

AbortController не шарится межу потоками. Статья по этому поводу https://webjose.hashnode.dev/finally-cancel-web-workers-work-without-terminating-the-worker

Но можно сделать аналог с помощью SharedArrayBuffer. В основном потоке писать в SharedArrayBuffer признак «останови поиск», в потоке поиска проверять.

Пробовали работать с indexeddb из воркера? Тогда бы нагрузка на поиск и фильтрацию не влияла бы на основной поток.

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

IndexDb не пробовал.

Поставил лайк за редактор блок-схем. Очень годная вещь получилась.

👍

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации