Большое дерево: когда выпускать данные в RIA - PullRequest
2 голосов
/ 13 ноября 2008

Этот вопрос касается Java JTree, дерева Window .Net (Winforms) или дерева Adobe Flex.

В клиент-серверном приложении (на самом деле для Flex это Web) у меня есть дерево с иерархическими данными (в интерфейсе типа Windows Explorer). Прямо сейчас я лениво загружаю дерево, поскольку пользователь запрашивает больше данных с сервера. Это нормально и будет работать до 750 тыс. Узлов (эмпирически протестировано на .Net Winforms и Adobe Flex), но после этого оно становится вялым. Но базы данных растут быстро (в основном потому, что пользователи могут вставлять огромное количество узлов), и база данных из 20 миллионов узлов вовсе не маловероятна.

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

Все это выглядит как большая работа, чтобы не допустить исчерпания памяти.

Редактировать: Должен ли я публиковать данные при развале узла? Если да, то когда? Идея кэширования слабых объектов хороша, но я должен просто продолжать заполнять пользовательский интерфейс, пока он не перестанет работать (возможно, это не плохая идея)?

Ответы [ 2 ]

1 голос
/ 13 ноября 2008

Если пользователи не свернут ветки, то, я думаю, они будут прокручивать узлы от 750К до 20М, верно? Мне кажется довольно неэффективным от пользователя POV. Таким образом, проблема вполне может быть решающей.

1 голос
/ 13 ноября 2008

в большинстве фреймворков, которые я видел, сама древовидная структура довольно эффективна, но если у вас есть нетривиальный объект на каждом листе дерева, он быстро добавляет.

проще всего было бы не хранить что-либо на листьях дерева, а в методе рендеринга / рисования / обновления / любого другого выбора выбрать объект из кеша со слабыми ссылками. если его там нет, загрузитесь с сервера. Хитрость заключается не в том, чтобы хранить какую-либо другую ссылку на объект, а только на слабую в кеше. таким образом, он все еще будет доступен, но будет собран при необходимости.

...