forked from UNN/2026-rff_mp
[1] laba_1
[1] лабораторная работа 1
This commit is contained in:
parent
2f896f1f87
commit
0ce55669c3
43
kalinovskiymi/otchet_1.md
Normal file
43
kalinovskiymi/otchet_1.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
Отчёт по лабораторной работе "Структуры данных"
|
||||
|
||||
1. Введение
|
||||
В рамках работы были реализованы три структуры данных для телефонного справочника: связный список, хеш-таблица и бинарное дерево поиска (BST). Проведено экспериментальное сравнение производительности операций вставки, поиска и удаления на наборе из 1000 записей. Каждая структура тестировалась на двух вариантах входных данных: случайный порядок и отсортированный по имени. Все эксперименты повторялись пять раз с последующим усреднением результатов.
|
||||
|
||||
2. Вывод результатов:
|
||||
Структура | Режим | Вставка, с| Поиск, с | Удаление, с
|
||||
LinkedList | Случайный | 0.027106 | 0.004267 | 0.002981
|
||||
LinkedList | Сорт. | 0.054406 | 0.004726 | 0.003020
|
||||
HashTable | Случайный | 0.000654 | 0.000053 | 0.000028
|
||||
HashTable | Сорт. | 0.000472 | 0.000036 | 0.000021
|
||||
BST | Случайный | 0.002561 | 0.000156 | 0.000250
|
||||
BST | Сорт. | 0.109515 | 0.005790 | 0.005869
|
||||
|
||||
Графическое представление результатов приведено на рисунке в файле benchmark_results.png
|
||||
|
||||
3. Анализ результатов
|
||||
3.1. Влияние порядка данных на BST
|
||||
При поступлении записей в отсортированном виде BST вырождается в связный список: каждый новый узел добавляется исключительно в правое поддерево. Глубина дерева достигает N, а сложность операций деградирует до O(n). Эксперимент подтверждает это:
|
||||
Вставка отсортированных данных заняла 0.111692 с — это в 42.9 раз медленнее, чем на случайных данных (0.002601 с).
|
||||
На отсортированных данных BST проиграло даже связному списку из-за накладных расходов на рекурсию.
|
||||
3.2. Устойчивость хеш-таблицы к порядку данных
|
||||
Хеш-функция равномерно распределяет ключи по корзинам вне зависимости от порядка поступления. Производительность остаётся стабильной:
|
||||
Вставка: 0.000681 с (случайный) и 0.000665 с (отсортированный).
|
||||
Поиск: около 0.0006857 с в обоих режимах.
|
||||
Незначительные колебания вызваны случайным характером коллизий.
|
||||
Это согласуется с теоретической оценкой средней сложности O(1).
|
||||
3.3. Причины медленного поиска в связном списке
|
||||
Отсутствие прямого доступа вынуждает последовательно обходить узлы, что даёт сложность O(n):
|
||||
Поиск в списке (0.004320 с) существенно уступает хеш-таблице (0.000054 с) и BST на случайных данных (0.00018099 с).
|
||||
С ростом объёма разрыв будет только увеличиваться.
|
||||
Вставка также медленная (2,8 с), поскольку при уникальных именах каждый раз приходится проходить весь список до конца.
|
||||
3.4. Сравнение удаления в трёх структурах
|
||||
Связный список: поиск элемента за O(n), затем изменение указателей за O(1). Время удаления (0.003085 с) практически совпадает со временем поиска.
|
||||
Хеш-таблица: определение корзины за O(1) и удаление из короткого списка. Время удаления (0.000031 с) на два порядка ниже, чем в списке.
|
||||
BST: на случайных данных удаление выполняется за 0.000139 с благодаря логарифмической высоте. На отсортированных данных время возрастает до 0.006047 с, что отражает деградацию до O(n).
|
||||
|
||||
4. Выводы и практические рекомендации
|
||||
На основе полученных экспериментальных данных можно сформулировать следующие рекомендации:
|
||||
Хеш-таблица — оптимальный выбор, когда приоритетна скорость операций вставки, поиска и удаления, а упорядоченность данных не требуется. Идеально подходит для словарей, кэшей, индексных хранилищ. В тестах показала стабильно высокую производительность во всех сценариях.
|
||||
Бинарное дерево поиска следует применять, когда необходимо получать данные в отсортированном виде (например, вывод справочника по алфавиту). Однако критический недостаток — деградация до O(n) на упорядоченных входных данных. В таких ситуациях стоит использовать сбалансированные деревья (AVL или красно-чёрные). В эксперименте BST на случайных данных работало почти наравне с хеш-таблицей, а на отсортированных показало худшие результаты.
|
||||
Связный список малопригоден для больших объёмов из-за линейной сложности операций. Оправдан лишь для маленьких коллекций, задач с частыми вставками в начало (в данном тестировании не рассматривались) или в учебных целях.
|
||||
Итог: в реальных проектах выбор стоит между хеш-таблицами и сбалансированными деревьями — в зависимости от того, насколько важна отсортированность хранимых данных.
|
||||
Loading…
Reference in New Issue
Block a user