Отчет по заданию 1: структуры данных

Цель

Реализовать три структуры данных с нуля в процедурной парадигме и сравнить скорость основных операций телефонного справочника:

insert(name, phone) - добавить или обновить запись;
find(name) - найти телефон по имени;
delete(name) - удалить запись;
list_all() - получить все записи, отсортированные по имени.

Классы не использовались. Узлы связного списка и дерева представлены словарями, хеш-таблица представлена списком бакетов.

Реализация

Код находится в файле phonebook.py.

Реализованы функции:

связный список: ll_insert, ll_find, ll_delete, ll_list_all;
хеш-таблица: create_hash_table, ht_insert, ht_find, ht_delete, ht_list_all;
двоичное дерево поиска: bst_insert, bst_find, bst_delete, bst_list_all.

Для хеш-таблицы используется метод цепочек: каждый бакет хранит голову связного списка. Хеш-функция написана вручную, чтобы результат не зависел от рандомизации встроенной функции hash() в Python.

Для BST вставка, поиск, удаление и обход написаны без классов. Обход bst_list_all реализован итеративно, чтобы отсортированный вход на 10000 элементов не приводил к переполнению стека рекурсии.

Методика эксперимента

Скрипт эксперимента находится в файле benchmark.py.

Параметры запуска:

количество записей: N = 10000;
число повторов каждого эксперимента: 5;
имена: User_00000, User_00001, ..., User_09999;
два режима входных данных: shuffled и sorted;
поиск: 100 существующих имен и 10 отсутствующих;
удаление: 50 случайных существующих имен;
размер хеш-таблицы: 20011 бакетов.

После вставки структура не пересоздается: поиск и удаление выполняются на той же заполненной структуре. Для каждого режима и каждой структуры создается новая структура.

Файлы с результатами:

docs/data/results.csv - все отдельные замеры;
docs/data/summary.csv - среднее время и список всех пяти замеров;
docs/data/performance.svg - столбчатая диаграмма средних значений.

Средние результаты

Время указано в секундах.

Структура	Режим	Вставка	Поиск	Удаление
LinkedList	shuffled	1.555942	0.014180	0.006345
LinkedList	sorted	1.513740	0.012993	0.006041
HashTable	shuffled	0.005934	0.000056	0.000031
HashTable	sorted	0.006140	0.000056	0.000029
BST	shuffled	0.011223	0.000093	0.000069
BST	sorted	2.250442	0.019857	0.010803

Анализ

Связный список оказался самым медленным на вставке и поиске. Причина в том, что для корректной операции insert нужно проверить, есть ли уже запись с таким именем. При уникальных именах почти каждая вставка проходит по всему текущему списку, поэтому суммарная сложность вставки всех записей становится O(n^2). Порядок входных данных почти не влияет на результат, потому что структура не использует порядок ключей.

Хеш-таблица показала лучшие результаты почти во всех операциях. При хорошем распределении по бакетам вставка, поиск и удаление близки к O(1). Порядок входных данных почти не влияет на время, так как индекс бакета определяется хешем имени, а не расположением записи во входном списке.

BST хорошо работает на перемешанных данных: дерево получается сравнительно сбалансированным, поэтому операции близки к O(log n). На отсортированном входе обычное двоичное дерево поиска вырождается в цепочку: каждый новый ключ становится правым потомком предыдущего. Из-за этого вставка всех записей становится O(n^2), а поиск и удаление приближаются к поведению связного списка.

Удаление у хеш-таблицы быстрое по той же причине, что и поиск: сначала вычисляется бакет, затем просматривается короткая цепочка. В BST удаление быстрое на перемешанном дереве, но на вырожденном дереве оно замедляется. В связном списке удаление требует линейного поиска удаляемого элемента.

Вывод

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

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

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

7.4 KiB Raw Blame History Unescape Escape