С включенным appendOnly, присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы остаются в списке визуализации даже если они выходят за рамки видимой и буферной области, что значительно увеличивает потребление ресурсов "железа". При скролле с помощью передвижения "ползунка", наблюдаются лаги и проседание производительности.
С выключенным appendOnly, не присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы удаляются из списка визуализации, что ни как не влияет на излишнее потребление ресурсов "железа", как в предыдущем примере. При скролле наблюдаются дёрганияб флики и не корректные репозиции при адаптивных по высоте элементах.
ng-virtual-list
ng-virtual-list удовлетворяет прохождению всех условий тестирования.
cdk-virtual-scroll-viewport (*ngVirtualFor) не подходит для решения задач, когда необходимы динамические по высоте элементы и требуется отрендерить очень большие списки, да так чтобы всё отрабатывало плавно и без проседания производительности в виде лагов.
У ng-virtual-list стабильность работы и производительность выше чем у cdk-virtual-scroll-viewport
P.S. Честно не проверял, работает ли scrollToIndex корректно при адаптивных по высоте контента элементах у cdk-virtual-scroll-viewport. Но могу утверждать про ng-virtual-list, что scrollToItem работает должным образом!
Видимо @aw350me имел ввиду, что каждый обработчик кнопки (trigger) регистрируется в массиве "слушателей", тем самым давая нагрузку на общую производительность списков. Про картинки наверное подобная история, только дающая дополнительную нагрузку на RAM и CPU. В случае с виртуализированными списками, триггеры и обработчики изображений лимитируется и не требуют вертикального масштабирования за счёт ресурсов "железа".
Сделал небольшой бенчмарк для сравнения. Выборка 100 000 элементов.
К каждому из решений приведены ссылки на демо. Можете убедиться сами в колоссальном различии потребления ресурсов!
Результат:
Инициализация ng-virtual-list списка (на моей машине) заняла ~3 секунды.
Инициализация обычного HTML списка (на моей машине) заняла ~20 секунд.
Нагрузка на CPU у ng-virtual-list меньше в ~10 в раз по сравнению со стандартными HTML списками.
Нагрузка на RAM у ng-virtual-list меньше ~10 в раз по сравнению со стандартными HTML списками.
Под инициализацией списка подразумевается общее время до отображения списка. Оно складывается из генерации коллекции случайными данными и построениями объектов экранной области.
Погнали,
Условия тестирования:
cdk-virtual-scroll-viewport (*ngVirtualFor)
При одном варианте использовался appendOnly, в другом без него. Оба варианта не удовлетворяют прохождение условий.
appendOnly="true"https://benchmark-cdk-virtual-scroll-viewport-appendonly.eugene-grebennikov.pro/
С включенным appendOnly, присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы остаются в списке визуализации даже если они выходят за рамки видимой и буферной области, что значительно увеличивает потребление ресурсов "железа". При скролле с помощью передвижения "ползунка", наблюдаются лаги и проседание производительности.
appendOnly="false"https://benchmark-cdk-virtual-scroll-viewport.eugene-grebennikov.pro/
С выключенным appendOnly, не присутствует возможность создавать группы со sticky лэйаутом. При последующих скроллах, элементы удаляются из списка визуализации, что ни как не влияет на излишнее потребление ресурсов "железа", как в предыдущем примере. При скролле наблюдаются дёрганияб флики и не корректные репозиции при адаптивных по высоте элементах.
ng-virtual-list
ng-virtual-list удовлетворяет прохождению всех условий тестирования.
https://benchmark-ng-virtual-list.eugene-grebennikov.pro/
P.S. Честно не проверял, работает ли scrollToIndex корректно при адаптивных по высоте контента элементах у cdk-virtual-scroll-viewport. Но могу утверждать про ng-virtual-list, что scrollToItem работает должным образом!
Видимо @aw350me имел ввиду, что каждый обработчик кнопки (trigger) регистрируется в массиве "слушателей", тем самым давая нагрузку на общую производительность списков. Про картинки наверное подобная история, только дающая дополнительную нагрузку на RAM и CPU. В случае с виртуализированными списками, триггеры и обработчики изображений лимитируется и не требуют вертикального масштабирования за счёт ресурсов "железа".
Поправка: выборка в тестах составила 200 000 элементов, а не 100 000 как написано в комментарии выше.
Сделал небольшой бенчмарк для сравнения. Выборка 100 000 элементов.
К каждому из решений приведены ссылки на демо. Можете убедиться сами в колоссальном различии потребления ресурсов!
Результат:
Инициализация ng-virtual-list списка (на моей машине) заняла ~3 секунды.
Инициализация обычного HTML списка (на моей машине) заняла ~20 секунд.
Нагрузка на CPU у ng-virtual-list меньше в ~10 в раз по сравнению со стандартными HTML списками.
Нагрузка на RAM у ng-virtual-list меньше ~10 в раз по сравнению со стандартными HTML списками.
Virtual list (ng-virtual-list):
https://benchmark-virtual-list.eugene-grebennikov.pro/
Simple HTML list:
https://benchmark-simple-list.eugene-grebennikov.pro/
Итог:
Решайте сами для кого и в каких случаях данная технология интересна или не интересна. Тесты и цифры говорят сами за себя.
P.S.: Тест не является чистым. Т.к. в примере со стандартным HTML списком не использовал sticky layout для групп (решил не добивать окончательно).