2026-rff_mp/raskatovia/docs/task1report.md

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

 Что было реализовано
 Связный список
Узел списка хранит имя, телефон и ссылку на следующий элемент. При добавлении запись создаётся или обновляется если такое имя уже есть. Использованы функции ll_insert; ll_find; ll_delete; ll_list_all. [с этой структурой было проще всего начать, потому что логика достаточно прямая]

 Хеш таблица
Хеш таблица сделана как набор ячеек для записей. Для имени вычисляется место куда его сохранить. Если в этом месте уже есть записи они хранятся вместе в связном списке. Использованы функции ht_create; ht_insert; ht_find; ht_delete; ht_list_all. [здесь пришлось отдельно разобраться что делать если несколько имён попадают в одно место. В итоге для таких записей внутри одной ячейки используется связный список]

 Двоичное дерево поиска
В каждом узле дерева хранятся имя, телефон, левый и правый потомок. Записи размещаются по имени поэтому их можно вывести в отсортированном виде. Использованы функции bst_insert; bst_find; bst_delete; bst_list_all. [с удалением в дереве пришлось посидеть дольше всего. Ну если коротко у удаления в дереве несколько случаев: удаляется лист, у узла есть один потомок, у узла есть два потомка, тогда его нужно заменить ближайшим подходящим элементом]

 Проверка работы
В файле tests.py были сделаны простые проверки для всех трёх структур. Я проверил добавление записей; изменение телефона у уже существующего имени; поиск существующей и несуществующей записи; удаление и вывод списка по алфавиту. по результатам запуска всё сработало корректно. [было важно проверить основные операции ещё до замеров]

 Замеры времени
Для сравнения был создан набор из 10000 записей. Использовались два варианта случайный порядок и отсортированный порядок. Для каждой структуры измерялось время вставки всех записей; поиска 110 имён; удаления 50 записей. Каждый замер повторялся 5 раз. Средние значения приведены ниже а полные результаты сохранены в results.csv. [здесь пришлось отдельно разбираться как нормально замерять время. Сначала было не очень понятно как сравнивать структуры честно, потом сделал несколько повторов для каждого случая и считал среднее время]

 Результаты
Связный список; случайный порядок; вставка 17.54 сек; поиск 0.145 сек; удаление 0.086 сек.
Связный список; отсортированный порядок; вставка 15.01 сек; поиск 0.127 сек; удаление 0.074 сек.
Хеш таблица; случайный порядок; вставка 0.896 сек; поиск 0.008 сек; удаление 0.005 сек.
Хеш таблица; отсортированный порядок; вставка 1.253 сек; поиск 0.008 сек; удаление 0.005 сек.
BST; случайный порядок; вставка 0.063 сек; поиск 0.0006 сек; удаление 0.0003 сек.
BST; отсортированный порядок; вставка 23.08 сек; поиск 0.170 сек; удаление 0.097 сек.

 Анализ
По замерам видно что связный список медленно работает при вставке. Перед добавлением новой записи программа идёт по списку и проверяет нет ли уже такого имени. На 10000 записей это уже заметно. Поиск тоже идёт простым перебором. [вот тут стало понятнее почему список быстро начинает тормозить]

Хеш таблица показала себя намного быстрее. Записи были и перемешанные и уже отсортированные но большой разницы во времени почти не получилось. [этот результат как раз хорошо показал зачем вообще нужна такая структура]

BST на случайных данных оказался самым быстрым. А вот на отсортированных данных дерево сильно замедлилось. Оно вытягивается почти в одну линию и начинает работать похоже на список. Поэтому вставка заняла около 23 секунд вместо 0.06. [при подготовке замеров стало понятно что на отсортированных данных дерево сильно вытягивается в одну сторону, а старая рекурсивная версия могла плохо отработать на 10000 записей Поэтому часть работы с Бст пришлось переделать без рекурсии]

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