Оптимальное хранение StringList в памяти.

← →
Карелин Артем © (2003-04-11 07:36) [0]

Сделал в программе функции инкрементального поиска данных при вводе данных (как в IE при наботе адреса). Данные для подстановки загружаются из базы 1 раз, но в нужные контролы (у них свои списки) передаются при показе нужной формы. Списков много, данных в них тоже много.
Как оптимальнее хранить списки, чтобы расходы памяти были не слишком большие и вместе с тем быстро загружались в контролы?

← →
Digitman © (2003-04-11 10:30) [1]

Видимо, придется разработать свои визуальные списочные контролы (работающие со списками на базе TStringlist). Например, TSpecialComboBox = class(TCustomCombobox). Иначе неразумные затраты памяти и ограничения в производительности (из-за бесконечных операций копирования и перераспределения памяти под элементы-строки) вряд ли удастся обойти.

Скажем, строка TargetComboBox.Items := SourceStringList приводит к созданию в "недрах" ComboBox"а точной копии оригинального списка, хотя все что нужно в данном случае - просто сослаться на существующий оригинальный объект-список (благо изменяться он с момента загрузки выборкой из БД и на всем протяжении работы приложения не будет). К сожалению, защищ.метод SetItems - не виртуальный и это несколько осложнит задачу наследования компонента. Сложность может еще возникнуть и в случае мультипоточного доступа к методам/св-вам оригин.списка. Но в принципе - все решаемо, и не так уж и сложно, особенно если делать ставку на немодифицирование содержания ориг.списка в момент пока существуют контролы. на него ссылающиеся.

← →
malkolinge © (2003-04-11 11:15) [2]

Лично мне НЕ нравиться как сделаны списки в делфи. Это и не списки а массивы ! Я бы писал Свой список с нуля. Сделал бы ему предка в виде TPersistenta И полностью бы перекрыл свойство Items.

Теперь, касаемо обновления - ИМХО лучше всего попытаться использовать древовидную структуру БД. Хотя я отлично понимаю, что это наверняка УЖЕ не реально.

← →
Digitman © (2003-04-11 11:28) [3]

> malkolinge

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

← →
malkolinge © (2003-04-11 11:38) [4]

Нет меня на программировании еще на первом курсе учили КАК сделать список. :) А посмотрите, что сделано у Борланда в этом направлении :)

← →
Digitman © (2003-04-11 12:31) [5]

> malkolinge

Борланд преследовал совершенноть иные цели, разработав и предложив эти классы/компоненты !)

А на первом курсе твое внимание, видимо, не заостряли на том, что делая классический список (с выделением/освобождением памяти под каждый эл-т индивидуально, думаю, это были New()/Dispose()), ты во многих случаях, во-первых, проигрываешь Борландовским алгоритмам по эффективности операций с памятью, во-вторых, неразумно дефрагментируешь адр.пространство, контролируемое встроенным менеджером памяти

← →
Palladin © (2003-04-11 12:38) [6]

> malkolinge © (11.04.03 11:38)

твое понятие списка, это ТВОЕ понятие спика...
меня тоже много чему учили...
но применять то или иное нужно исходя из ситуации

← →
Digitman © (2003-04-11 12:49) [7]

> Palladin (11.04.03 12:38)

совершенно верно !

← →
malkolinge © (2003-04-11 17:26) [8]

> Digitman ©

Я с вами абсолютно согласен в плане того, что выбор решения зависит от ситуации. Но Борландовский список занимает НАМНОГО больше места ( я не имею ввиду затраты на инкапсуляцию его в класс). Там как никак статический массив МАксимальной длинны указателей используеться.

← →
Palladin © (2003-04-11 17:46) [9]

> malkolinge © (11.04.03 17:26)

нет не статический, рассмотри получше исходники...
и заметь что есть свойство Capacity...

malkolinge © (11.04.03 17:26)
Твоя реализация требует намного больше памяти, времени на обработку списка и неэффективна в сущности.
У Борланда очень эффективная реализация, к тому же можно управлять этой эффективностью.

Как было сказано в ожной рекламе - Вы просто не умеете их готовить.

Да вижу..Правда где это свойство по умолчанию задаеться пока не нашел....но ищу :))

> Твоя реализация требует намного больше памяти, времени на
> обработку списка и неэффективна в сущности.

Идея была в том, чтобы создать свой список. Это обычный пример, как правильно было замечено достаточно тривиальный и с массой недостатков

> У Борланда очень эффективная реализация, к тому же можно
> управлять этой эффективностью.

Если б я в этом сомневался, то писал бы на Вижуале

> Как было сказано в ожной рекламе - Вы просто не умеете их
> готовить.

Спасибо за оказанное доверие :)

← →
Serginio (2003-04-11 18:22) [13]

Может я что то не понял. Но такую проблему легко решать при помощи отсортированного TStringList. Если нужно его можно привязать к конкретному контролу. А в выпадающий список копировать по неполнрму совпадению которые лего отискиваются половинным делением. По поводу списков в Delphi которые по сути являются наследниками TList тоесть практически динамчекие массивы то здесь палка о двух концах. Самый большой недостаток это реаллоки которые при больших списках могут вызывать ошибку выделения памяти (из-за дефрагментации) борьба с этим явлением либо зная наперед какой размер списка сразу выделять (Capacity) либо переходить на дискретные (страничные списки в виде дерева либо динамического массива страниц).

Оптимальное хранение StringList в памяти. Найти похожие ветки