Большое дерево: когда выпустить данные в RIA

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

Простейшим было бы не хранить что-либо на листьях дерева, а на методе рендеринга/рисования/обновления/любого другого, выберете свой объект из кэша слабых-ref. если его нет, загрузите с сервера. трюк заключается не в том, чтобы содержать какую-либо другую ссылку на объект, а только в кэше. Таким образом, он будет по-прежнему доступен, но будет собран, когда это необходимо.