Неужели Tries все еще хорошая идея о современных архитектурах?

Одной из моих любимых структур данных в колледже была Trie. Это отличная структура данных для хранения большого набора строк, если префиксы являются общими. Поиск также хорош, поскольку они выполняются в строке O (| length |), независимо от того, сколько строк в наборе.

Для сравнения, сбалансированное дерево будет O (log N) в количестве заданных элементов, плюс все, что вы платите за сравнения. Хэш-таблица будет включать в себя вычисление хэша, сравнение и т.д.

Поэтому мне удивительно, что не существует реализации Trie в стандартной библиотеке большинства языков.

Единственная причина, по которой я мог придумать, - это возможность того, что затраты на доступ к памяти делают это слишком дорогостоящим. Вместо того, чтобы исследовать местоположения O (log N), если вы выполняете поиск по дереву, вы не делаете O (| length |) разных местоположений со всеми вытекающими последствиями. Если строки длинны, это может оказаться слишком большим.

Итак, мне интересно: сколько всего я только что назвал проблемой? Что вы делаете, когда вам нужно хранить большой набор или карту строк?

Ответ 1

Я раньше не думал об этом как о проблеме, но теперь, когда вы упоминаете об этом, бывают случаи, когда стандартная реализация Trie может быть удобной. С другой стороны, насколько я знаю, Tries используются Python и Perl и другими языками, которые я использую сейчас.

Последнее, что я проверил, который был давным-давно, в коде кода BSD использовался Tries (Patricia Tries) в коде, чтобы выбрать лучший интерфейс для отправки пакетов. Похож на Википедия имеет некоторую информацию.

Ответ 2

Вы можете просто создать два примера приложений и посмотреть, какой из них лучше. Доступ к памяти дешев, если вы не ошибаетесь. Тогда это очень дорого. Для разработки клиентского приложения почти всегда лучше обрабатывать, чем для доступа к памяти именно по этой причине. Современные процессоры смехотворно быстрей, но промахи в кэше все еще болят.

Ответ 3

Я провел некоторое тестирование производительности на С# с помощью Trie и Dictionary (строго типизированная хеш-таблица). Я обнаружил, что Словарь был в 5-10 раз быстрее, чем Trie. Возможно, моя реализация Trie может быть оптимизирована немного, но вряд ли достаточно, чтобы быть намного быстрее, чем (или, возможно, даже быстрее) Словарь.

Метод ContainsKey в словаре близок к операции O (1) (в зависимости от того, насколько хорош алгоритм хэширования), поэтому нелегко сделать коллекцию, которая превосходит ее, если алгоритм хэширования достаточно быстр.

С помощью пользовательского IEqualityComparer вы можете использовать большинство всего в качестве ключа в словаре, что делает его довольно гибким. Trie немного более ограничен в том, что вы можете использовать в качестве ключа, так что это немного ограничивает полезность.