Всем спасибо за ответы.
Попробовал и LazyQueryContainer и Viritin.
LazyQueryContainer мне показался слишком замудреным с точки зрения написания фильтров и сортировок.
Пришлось добавлять дополнительные классы в код, заняло это прилично времени, так как примеров в интернете очень мало и они не свежие. А официальная документация скудна и так же содержит примеры их старых версий, многих методов нет или они переписаны по другому. ДжаваДоки хоть и есть и свежие, но не несут представления как именно использовать тот или другой класс и его методы совместно с другими, лишь краткое описание(в принципе так оно и должно быть).
Хотя работает отлично, при 1100_с небольшим строках, показал хорошую скорость подгрузки при прокручивании, при переходах в начало и конец таблицы.
В режиме редактирования, когда на каждую строку на определенные столбцы навешаны свои методы через TableFieldFactory,
скорость чуть хуже, но приемлемо.
В диспетчере задач хрома он показал примерно
130-160мб у вкладки с таблицей в обычном режиме и
160-190мб в режиме редактирования.
Возможно чуть больше, в общем до 210мб. При этом вполне возможно еще комфортно работать.
Далее я посмотрел Viritin и его MTable, который расширяет стандартный Table от Vaadin. (на нем, кстати останусь теперь для "проблемных" таблиц)
Подключить его заняло какие-то минуты и все сразу же взлетело. И сортировка и ленивая подгрузка.
При этом таблице достаточно дать коллекцию данных через myTable.setBeans(Collection<T> beans) и она будет использовать её через свой собственный контейнер, который вроде бы называется
LazyList , но я не стал вдаваться в подробности, может быть позже.
Теперь немного статистики для тех же данных, того же объема в 1100_с небольшим, объектов, то есть строк в MTable.
При просмотре таблицы, при хаотичной прокрутке, в том числе стрелками клавиатуры, постраничной прокрутке через пейдАп/Даун, хоум и енд (прошу прощения за названия на русском:) ) диспетчер задач хрома показывает примерно те же
140-160мб что и при использовании LazyQueryContainer.
180-210мб в режиме редактирования, вполне крутибильно и кликабельно получается.
Все эти "тесты" были проведены с использованием стилей css, которые включают в ячейках перенос слов, а высота ячейки и соответственно всей строки увеличивается. То есть высота строк становится различной и при просмотре и в режиме редактирования таблицы.
В итоге, все же, я решил, что в данном UI высоту строк сделаю под 2-е строки (если конкретно, то 40px).
Для сравнения: при тех же условиях стандартный IndexedContainer от Vaadin, без ленивой подгрузки, при вдвое меньшем количестве строк, то есть 500, почти сразу же начинает подтормаживать и чем дольше работать с таблицей, тем хуже.
500-600-800мб и выше отображаются в диспетчере задач хрома и это, повторюсь, при объеме вдвое меньшем.
Надо заметить, что для других сущностей/объектов БД, которые содержать меньше полей чем та, которую я тестировал, IndexedContainer работает сносно и даже очень хорошо. Или когда используется гораздо меньше столбцов в самой таблице и без фишек css, которые влияют на высоту строк. И менять его просто так не стоит, если он и так справляется с данными.
п.с. нужно не забывать при работе с Table про такие параметры как table.setPageLength(int) и table.setCacheRate(int), они так же влияют на скорость отображения таблицы и работы в ней/с ней.
