forked from UNN/2026-rff_mp
35 lines
2.0 KiB
Markdown
35 lines
2.0 KiB
Markdown
|
Лабораторная работа 1
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Цель работы
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Нужно было сделать три структуры данных и проверить как они работают на телефонном справочнике.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Ход работы
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Сделал связный список хеш таблицу и двоичное дерево поиска. Для всех структур сделал добавление поиск удаление и вывод записей. Для проверки создал 10000 записей с именами User\_00000 и т.д. Потом проверил работу со случайным порядком и с отсортированным порядком. Каждый эксперимент повторял 5 раз.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Результаты
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Результаты сохранились в results.csv. Также сделал графики для добавления поиска и удаления. По результатам видно что связный список медленно ищет записи потому что нужно идти по элементам. Хеш таблица работает примерно одинаково при разном порядке записей. У двоичного дерева порядок записей влияет намного сильнее. Если добавлять записи по порядку дерево становится похожим на обычный список и работает медленнее.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Вывод
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
В работе я сделал три структуры данных и проверил их работу. Самой удобной для телефонного справочника получилась хеш таблица. Связный список проще но поиск медленный. Двоичное дерево может работать быстро но сильно зависит от порядка добавления данных.
|
|||
|
|
|