1) Ерунда. Структуры не хранятся в коллекции, а в случае объектов нет нужды в коллекции — достаточно второго способа.

3) Массив структур. В Tag хранится индекс массива.

CyraxНу, если в Tag структуру можно запихнуть , то думаю, и в коллекцию проблем не составит.Если практика извращений для вас не составляет проблем, флаг в руки.

CyraxПочему же. В случае с коллекцией объектов можно вообще обойтись без поля Tag (это поле можно будет использовать для семантически иных данных/целей) То есть вы еще даже с целями не определились?

Cyrax1. Длина массива ограничена размерностью типа Integer. Дерево (БД) может содержать гораздо больше узлов (записей).Дерево, содержащее такое количество узлов, само по себе является недостатком. Единственное ему применение — реестр. Но в regedit и узлы подгружаются динамически.
Cyrax2. Удаление элемента из массива очень трудоёмко (перекладывание + ReDim)Зависит от структуры. Если там нет строк нефиксированной длины и массивов, то CopyMemory за раз все сдвинет, а redim необязателен, можно запоминать максимальный индекс и не ходить дальше по массиву.

Cyrax2. Имхо, использование CopyMemory при работе с массивами - явный признак ошибочного выбора структур данныхЭто явный признак того, что скорость работы критична.

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

А ссылки на объекты это Long, поля постоянной длинны.

CyraxКак по мне, если критична скорость работы, то целесообразно в данном случае выбрать иные структуры данных,Мы вроде негласно договорились называть структурами Public Type. Здесь уместно сказать "хранилища".
Cyrax где можно удалять элементы без сдвигов и иных операций, не свойственных массивам.Это зависит от задачи. Если 99% нагрузки программы на процессор заключается в поиске по индексу, а удаление/добавление происходит эпизодически, то коллекции безнадежно сливают массивам. А если 99% это перетряхивание его содержимого, то... нужно замерять. В реализации быстрых массивов гораздо больше букв, а скорость в 9 случаях из 10 не критична, поэтому коллекции удобнее.
CyraxТак вот, "запихивание" структур в Variant - это не большее извращение, чем использование CopyMemory при работе с массивами.Использование CopyMemory это не извращение, а признак того, что человек наконец-то разобрался, что представляет из себя память компьютера и данные в ней. И от этого получает бонус в виде более шустрых процедур. А "запихивание" структур в Variant это извращение чистой воды. Во-первых, лишняя писанина, во-вторых проигрыш в скорости. Кто-то может объяснить, зачем это надо?
CyraxВыигрышь в скорости будет незначительный, к тому же можно реализовать динамическую подгрузку узлов.Если заменить цикл на CopyMemory, выигрыш в скорости будет потрясающий. Я говорю о том, что видел и делал.
CyraxИменно поэтому массивы и не пригодны для таких целей.Каких целей конкретно? Вы все говорите о каких-то целях, но мне не удается угадать ваше ТЗ.

CyraxДля целей хранения данных непостоянной длины. Например, динамических строк.Это не цель. Цель это то, что достигается путем хранения динамических строк.
CyraxКакой ещё цикл ? Мы сравниваем скорость работы с массивом структур и с иными "хранилищами" (так уж и быть), позволяющими удалять элементы без несвойственных этим хранилищам операций, т.е. штатными средствами.Попробуйте удалить 100 элементов без цикла.
Удаление одного элемента из коллекции будет быстрее, чем сдвиг массива через CopyMemory. И то не факт. Удаление ста элементов — медленнее.
Если не будет очень лень, напишу таки тест.
CyraxСлишком много "если". А вы как думали? Лишь скурпулезный учет всех условий, в которых придется работать коду, даст наиболее производительный алгоритм.
CyraxОсновная нагрузка на процессор идёт при построении дерева.Я рассматривал массивы и коллекции в отрыве от всяких деревьев. Конечно, в таких условиях дерево является главным тормозом, и тут разница в скорости работы массивов и коллекций уходит на десятый план.
CyraxДа и вообще, скорость обработки данных критична прежде всего в системах реального времени.Расскажите это хардкорным геймерам и тем, кто часто кодирует видео.
авторА если не использовать CopyMemory, это значит, что человек лопух ? )))Это значит, что у него еще все впереди.