Добавление множества элементов в ListModel без блокировки пользовательского интерфейса

Question

Я реализовал поиск множества элементов (сотен) в JList с использованием Lucene - когда кто-то вводит текст в поле поиска, он выполняет поиск и отображает результаты в JList. Это делается путем добавления и удаления элементов из базовой модели JList при вводе каждого символа, но этот подход блокирует пользовательский интерфейс (поскольку добавление чего-либо в ListModel должно выполняться в EDT.) Поиск выполняется очень быстро, но это добавление и удаление элементов, которые занимают время.

Как бы я подошел к проблеме, чтобы не блокировать EDT во время модификации модели?

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

Другие детали:

• Я профилировал приложение, отставание определенно вызвано добавлением / удалением большого количества элементов. Типичным шагом может быть добавление или удаление любого количества элементов, от нескольких до сотен. Например, если я буду искать букву «х» в текстовом поле, то большинство элементов будут удалены, так как немногие содержат эту букву. Если я тогда удалю письмо, все пункты будут добавлены снова. Если я найду более общий термин, например «the», то можно будет удалить только несколько элементов, поскольку основная их часть содержит этот термин.

• Я не имею дело со строками напрямую, но это относительно простые объекты, состоящие из нескольких строк (точнее, песни, состоящей из названий, авторов, текстов песен и т. Д.), И они все они кешируются с использованием SoftReferences, где это возможно (поэтому предположим, что ни один из этих объектов не создается и не уничтожается, их не должно быть для обычного пользователя.)

Answer 1

Возможно, это не тот ответ, который вы ищете, но мне интересно, если ваше лучшее решение - просто не добавлять сотни элементов. Пользователь не сможет или не захочет прокрутить столько элементов в JList, и поэтому, возможно, ваш самый умный шаг - ограничить количество элементов, добавляемых к разумному числу, скажем, 20 или около того.

Мне кажется, что это похоже на текстовый процессор, отображающий документ на экране, или другие немедленные компоненты для поиска, которые я использовал в прошлом. Если документ большой, часто все это не загружается в память, а как-то кешируется на диск. Если у вас нет выбора, кроме как загрузить много элементов, то, возможно, вы можете взять эту часть модели в автономном режиме, показать модальное диалоговое окно ожидания, загрузить элементы из EDT, а затем вернуть модель в оперативный режим, а затем выпуск модального диалога.

Answer 2

Я думаю, что самым простым способом было бы использовать JTable вместо JList , добавить RowFilter к JTable, тогда нет никаких причин для add/remove/modify чисел Items

для add/remove/modify чисел Items в XxxModel на фоне есть SwingWorker