UNN/2026-rff_mp
20
16
Fork 116
Code Issues Pull Requests 6 Actions Packages Projects Releases Wiki Activity

Удалить SmirnovaVYu/report.md

Browse Source
This commit is contained in:
smirnovavyu 2026-09-04 14:54:13 +00:00
parent 2cb8d56df5
commit 792ebeb415
1 changed files with 0 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
SmirnovaVYu/report.md
View File

@ -1,89 +0,0 @@
# Отчёт по лабораторной работе
## Цель работы
Реализовать три структуры данных «с нуля» (связный список, хеш-таблица, двоичное дерево поиска), применить их для хранения записей телефонного справочника и экспериментально сравнить производительность основных операций.
## Параметры эксперимента
- Количество записей: 10000
- Количество повторов каждого теста: 5
- Размер хеш-таблицы: 1000 корзин
## Результаты экспериментов
### 1. Связный список
| Режим | Вставка (сек) | Поиск (сек) | Удаление (сек) |
|-------|---------------|-------------|----------------|
| Случайный | 3.0333 | 0.0231 | 0.0157 |
| Отсортированный | 2.8224 | 0.0027 | 0.0003 |
### 2. Хеш-таблица
| Режим | Вставка (сек) | Поиск (сек) | Удаление (сек) |
|-------|---------------|-------------|----------------|
| Случайный | 0.1966 | 0.0007 | 0.0004 |
| Отсортированный | 0.1950 | 0.0001 | 0.0001 |
### 3. Двоичное дерево поиска (BST)
| Режим | Вставка (сек) | Поиск (сек) | Удаление (сек) |
|-------|---------------|-------------|----------------|
| Случайный | 0.0116 | 0.0001 | 0.0001 |
| Отсортированный | 3.0238 | 0.0003 | 0.0004 |
## Анализ результатов
### 1. Влияние порядка данных на BST
На отсортированных данных BST деградирует с O(log n) до O(n).
Время вставки увеличилось с 0.0116 до 3.0238 секунд — в 259.6 раз.
### 2. Почему хеш-таблица не чувствительна к порядку
Хеш-функция распределяет элементы случайно, порядок ввода не влияет на позицию элемента.
Разница между случайным и отсортированным порядком:
- Вставка: 0.1966 vs 0.1950
- Отношение: 0.99x (почти не чувствительна)
### 3. Почему связный список медленный при поиске
Поиск требует последовательного прохода O(n) без возможности индексации.
Поэтому связный список хорош только когда записей мало.
Для больших телефонных справочников он не подходит.
Сравнение скорости поиска (случайные данные):
- LinkedList: 0.0231 сек
- HashTable: 0.0007 сек (в 30.9 раз быстрее)
- BST: 0.0001 сек
### 4. Сравнение удаления
| Структура | Сложность | Время на 50 удалений (случайные данные) |
|-----------|-----------|------------------------------------------|
| Связный список | O(n) | 0.0157 сек |
| Хеш-таблица | O(1) в среднем | 0.0004 сек |
| BST | O(log n) в среднем | 0.0001 сек |
## Вывод:
| Задача | Рекомендация | Почему |
|--------|-------------|--------|
| Частый поиск | Хеш-таблица | O(1) в среднем, не зависит от порядка |
| Частые вставки/удаления | Хеш-таблица | Амортизированное O(1) |
| Нужен отсортированный вывод | Сбалансированное дерево (AVL/Red-Black) | In-order обход даёт сортировку |
| Мало данных (<100 элементов) | Связный список или массив | Простота, накладные расходы не оправданы |
| Последовательный доступ (очередь/стек) | Связный список | Вставка/удаление в начало/конец за O(1) |
## Заключение
Эксперимент наглядно демонстрирует:
1. **BST без балансировки опасен** — на отсортированных данных он деградирует до O(n)
2. **Хеш-таблица стабильна** — её производительность не зависит от порядка входных данных
3. **Связный список** подходит только для специфических задач с малым объёмом данных
## Дата выполнения
2026-05-21 14:44:41