Оптимизация вставок двоичного дерева в O (1) с хэш-картой для записи тяжелых деревьев - PullRequest
3 голосов
/ 07 декабря 2009

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

У меня довольно тяжелое двоичное дерево записи (около 50/50 между записью и чтением), и сегодня по дороге домой я думал о способах оптимизации этого, особенно об ускорении записи - это то, что я придумал .

Учитывая, что операция add (T, x) для добавления x в дерево T сначала состоит из find (T, x), чтобы увидеть, существует ли x, и в этом случае она не возвращает родителя, поэтому мы можем добавить это вместо одного из родителей пустые листья.

Что если мы добавим хеш-таблицу в качестве промежуточного кеша к операции добавления, поэтому, когда мы вызываем add (T, x), в действительности происходит то, что x хешируется и вставляется в хэш-карту M. И это все. Оптимизация происходит, когда мы где-то еще просим найти (T, x), теперь, когда мы ищем дерево, мы придем к листовому узлу, так как x еще не вставил дерево (оно существует только в хэш-карте M) , мы хэшируем x и сравниваем его с ключами в M, чтобы увидеть, должно ли оно быть в дереве. Если он найден в M, мы добавляем его в дерево и удаляем из M.

Это исключило бы операцию поиска (T, x) для add (T, x) и уменьшило бы ее до сложения (M, x), которое равно O (1). И затем (ab) - используйте операцию поиска (T, x), которая выполняется, когда мы ищем узел в первый раз, чтобы вставить его.

Ответы [ 2 ]

7 голосов
/ 07 декабря 2009

Почему бы не использовать хеш-таблицу для всего и полностью опустить двоичное дерево?

Все зависит от того, почему вы использовали двоичные деревья. Если вы выбрали двоичные деревья для улучшения общего доступа, вы теряете с кэшем хеш-таблицы, потому что хеш-таблицы не являются общими.

Кэши также не упрощают сравнение двух карт.

РЕДАКТИРОВАТЬ:

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

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

5 голосов
/ 07 декабря 2009

Если вам нужно иметь структуру с O (1) вставками и приблизительно O (n) амортизированной упорядоченной итерацией, у меня возникла та же проблема:

Диктофон с ключами в Python

Ответ (ведение хеша и частично отсортированного списка и использование сортировки по структуре с частично отсортированной структурой, такой как TimSort) на практике в моем случае работал очень хорошо.

...