2026-rff_mp/kalinovskiymi/docs/otchet_1.md

43 lines
7.0 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.

Отчёт по лабораторной работе "Структуры данных"
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 на случайных данных работало почти наравне с хеш-таблицей, а на отсортированных показало худшие результаты.
Связный список малопригоден для больших объёмов из-за линейной сложности операций. Оправдан лишь для маленьких коллекций, задач с частыми вставками в начало (в данном тестировании не рассматривались) или в учебных целях.
Итог: в реальных проектах выбор стоит между хеш-таблицами и сбалансированными деревьями — в зависимости от того, насколько важна отсортированность хранимых данных.