Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Внизнужен список ключ-значение. Найти похожие ветки
← →
Бумбурум (2012-02-12 19:41) [0]нужен быстрый список типа ключ-значение. (Стринг-Поинтер)
где такой можно взять? скорость очень важна.
делал TList с элементами такого типа:
type
TItem = packed record
Key: string;
Data: Pointer;
end;
поиск тупой в лоб, через фор.
но не думаю, что это так быстро как нужно.
← →
Сергей М. © (2012-02-12 19:43) [1]
> где такой можно взять?
Ты не поверишь - он прямо перед носом: TStringList
← →
DVM © (2012-02-12 19:56) [2]
> Бумбурум (12.02.12 19:41)
> поиск тупой в лоб, через фор.
отсортируй значения и поддерживай список отсортированным и вот уже поиск не тупой можно применить а бинарный, быстрее будет только хэш таблица.
← →
TUser © (2012-02-12 20:22) [3]
> скорость очень важна
писать свое, возможно, хэш-таблица, суффиксное дерево, массив+бинарный поиск, ...
> но не думаю, что это так быстро как нужно.
ты думаешь или проверял?
← →
Dimka Maslov © (2012-02-12 20:25) [4]
> отсортируй значения и поддерживай список отсортированным
> и вот уже поиск не тупой можно применить а бинарный
В отсортированном стринглисте поиск сам по себе уже бинарный применяется.
← →
Бумбурум (2012-02-12 20:25) [5]
>
> TUser © (12.02.12 20:22) [3]
>
> ты думаешь или проверял?
мне сказали про некие черно-красные деревья.
← →
MBo © (2012-02-12 20:33) [6]http://www.torry.net/pages.php?id=279
Известные названия оттуда:
ACED
AntiDOT
Collections
DIContainers
DeHL
GPLists
SDL
← →
DVM © (2012-02-12 20:43) [7]
> скорость очень важна.
если количество элементов не запредельно, то бинарный поиск может даже превосходить по скорости хэш таблицы, если последние заполнены существенно и создается масса коллизий в них. При интенсивном удалении хэш таблица тоже деградирует в плане скорости. Короче в 99% задач отсортированного списка за глаза, а в 80% и не отсортированного с тупым for
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.46 MB
Время: 0.101 c