2026-rff_mp/KislyuninED/docks/report_1-st-exersize.md

Отчёт по лабе: телефонный справочник на трёх структурах

Что делал

Реализовал три структуры для хранения записей (имя – телефон) без классов, только словари и ссылки:

1. Связный список – каждый узел {'name': ..., 'phone': ..., 'next': ...}.
   Вставка в начало, перед этим проверка на дубликат (поиск по всему списку).

2. Хеш-таблица – 13 корзин, в каждой связный список. Хеш-функция: сумма кодов символов % 13.
   Вставка/поиск/удаление – через хеш + вызов функций списка для конкретной корзины.

3. Двоичное дерево поиска – узел {'name': ..., 'phone': ..., 'left': ..., 'right': ...}.
   Вставка и поиск итеративные (циклы), удаление рекурсивное с поиском inorder‑преемника.

Операции везде: insert, find, delete, list_all (для дерева – обход по порядку, для остальных – собрать всё в список и отсортировать).

Эксперимент

Взял 1000 записей вида User_00001 … User_01000.
Подготовил два набора: случайный порядок и отсортированный по имени.

Для каждой структуры и каждого набора:

• Замерял время вставки всех 1000 записей (через time.perf_counter()).
• Затем поиск 110 имён (100 реальных + 10 вымышленных).
• Потом удаление 50 случайных записей.

Каждый замер повторял 5 раз, брал среднее.
Результаты сохранил в results.csv, потом построил график performance.png.

Что получилось (график)

Анализ

BST
На случайных данных работал очень быстро (логарифм). А на отсортированных – ужасно: дерево выродилось в правую цепочку, высота стала 1000. Вставка замедлилась в ~58 раз, поиск и удаление тоже сильно просели. Это классическая проблема небалансированного дерева.

Хеш-таблица
Порядок данных почти не влияет. И в случайном, и в отсортированном режимах время одинаковое. Хеш-функция разбрасывает записи по корзинам, поэтому ей всё равно, откуда приходят данные.

Связный список
Ожидаемо медленный везде, потому что поиск всегда линейный (O(n)). Разницы между случайным и отсортированным нет – список не умеет использовать порядок.

Удаление – похоже на поиск по скорости, плюс чуть-чуть на перестановку ссылок. У хеш-таблицы удаление быстрее всего.

Выводы

• Хеш-таблица – лучший выбор, если нужен быстрый поиск и порядок вывода не важен. Стабильна и проста.
• Двоичное дерево поиска – хороший вариант, если часто нужен отсортированный список, но только при случайных данных. Если данные могут прийти отсортированными, дерево сломается (станет как список). Надо брать сбалансированное (AVL, красно-чёрное).
• Связный список – для реальной базы контактов не годится. Можно использовать только когда записей совсем мало (до сотни) или чисто в учебных целях.

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