2026-rff_mp/ZelentsovAV/task1/docs/report.md
2026-05-24 20:18:54 +03:00

86 lines
5.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Отчёт по лабораторной работе
## Цель работы
Реализовать три структуры данных «с нуля» (связный список, хеш-таблица, двоичное дерево поиска), применить их для хранения записей телефонного справочника и экспериментально сравнить производительность основных операций.
## Параметры эксперимента
- Количество записей: 10000
- Количество повторов каждого теста: 5
- Размер хеш-таблицы: 1000 корзин
## Результаты экспериментов
### 1. Связный список
| Режим | Вставка (сек) | Поиск (сек) | Удаление (сек) |
|-------|---------------|-------------|----------------|
| Случайный | 6.2254 | 0.0446 | 0.0286 |
| Отсортированный | 5.9099 | 0.0058 | 0.0006 |
### 2. Хеш-таблица
| Режим | Вставка (сек) | Поиск (сек) | Удаление (сек) |
|-------|---------------|-------------|----------------|
| Случайный | 0.4748 | 0.0014 | 0.0006 |
| Отсортированный | 0.3728 | 0.0002 | 0.0001 |
### 3. Двоичное дерево поиска (BST)
| Режим | Вставка (сек) | Поиск (сек) | Удаление (сек) |
|-------|---------------|-------------|----------------|
| Случайный | 0.0240 | 0.0002 | 0.0001 |
| Отсортированный | 6.6866 | 0.0005 | 0.0008 |
## Анализ результатов
### 1. Влияние порядка данных на BST
При добавлении уже отсортированных элементов BST вырождается в линейную структуру — сложность падает с O(log n) до O(n).
Время вставки выросло с 0.0240 до 6.6866 секунд — замедление в 278.7 раза.
### 2. Почему хеш-таблица не чувствительна к порядку
Хеш-функция равномерно распределяет ключи по корзинам независимо от их исходного порядка. Поэтому последовательность добавления практически не влияет на производительность.
Сравнение случайного и упорядоченного ввода:
- Случайный режим: 0.4748 с
- Упорядоченный режим: 0.3728 с
- Различие: 0.79
### 3. Почему связный список медленный при поиске
Поиск в связном списке требует линейного обхода O(n) — структура не поддерживает произвольный доступ. Это делает его непригодным для крупных справочников, где нужен быстрый поиск по ключу.
Сравнение скорости поиска на случайных данных:
- LinkedList: 0.0446 сек
- HashTable: 0.0014 сек (преимущество в 30.8)
- BST: 0.0002 сек
### 4. Сравнение удаления
| Структура | Сложность | Время на 50 удалений (случайные данные) |
|-----------|-----------|------------------------------------------|
| Связный список | O(n) | 0.0286 сек|
| Хеш-таблица | O(1) в среднем | 0.0006 сек |
| BST | O(log n) в среднем | 0.0001 сек |
## Вывод:
| Задача | Рекомендация | Почему |
|--------|-------------|--------|
| Частый поиск | Хеш-таблица | O(1) в среднем, не зависит от порядка |
| Частые вставки/удаления | Хеш-таблица | Амортизированное O(1) |
| Нужен отсортированный вывод | Сбалансированное дерево (AVL/Red-Black) | In-order обход даёт сортировку |
| Мало данных (<100 элементов) | Связный список или массив | Простота, накладные расходы не оправданы |
| Последовательный доступ (очередь/стек) | Связный список | Вставка/удаление в начало/конец за O(1) |
## Заключение
Проведённый эксперимент подтверждает теоретические оценки сложности:
1. **Небалансированное BST это плохой выбор** при работе с реальными данными, которые могут оказаться упорядоченными. Деградация до O(n) делает его непригодным для надёжных систем.
2. **Хеш-таблица показывает стабильные результаты** вне зависимости от порядка входных данных ключевое преимущество для телефонного справочника с произвольными именами абонентов.
3. **Связный список — нишевый инструмент**, эффективный только при работе с малыми объёмами данных.