Як вибрати між картою та unordered_map?

Припустимо, я хотів зіставити дані із рядком як ключем. Який контейнер я повинен був вибрати, mapабо unordered_map? unordered_mapзаймає більше пам’яті, тож припустимо, пам’ять не є проблемою, а проблема полягає в швидкості.

unordered_mapяк правило, повинні давати середню складність O (1) з найгіршим випадком O (n). У яких випадках воно потрапляло б до O (n)? Коли час mapотримує більше часу, ніж unordered_map? Чи трапляється це, коли n мало?

Припускаючи, що я б використовував STL unordered_mapіз типовим хасером Vs. карта. рядок - це ключ.

Якщо я збираюся робити ітерацію над елементами, а не отримувати доступ до окремого елемента щоразу, чи слід віддавати перевагу map?

На практиці, якщо пам’ять не є проблемою, unordered_mapце завжди швидше, якщо ви хочете отримати доступ до одного елемента.

Найгірший випадок - теоретичний і пов’язаний з єдиним хешем, що враховує всі елементи. Це не має практичного значення. Він unordered_mapстає повільнішим, як тільки у вас є принаймні журнал N елементів, що належать одному хешу. Це також не має практичного значення. У деяких спеціальних сценаріях ви можете використовувати певний алгоритм хешування, який забезпечує більш рівномірний розподіл. Для звичайних рядків, які не мають певного шаблону, загальні хеш-функції, які unordered_mapпостачаються, є такими ж хорошими.

Якщо ви хочете пройти карту (за допомогою ітераторів) у сортуванні, ви не можете використовувати unordered_map. Навпаки, mapне тільки дозволяє це, але також може надати вам наступний елемент на карті на основі наближення ключа (див. lower_boundТа upper_boundметоди).

                       | map              | unordered_map
---------------------------------------------------------
element ordering       | strict weak      | n/a 
                       |                  |
common implementation  | balanced tree    | hash table
                       | or red-black tree|  
                       |                  |
search time            | log(n)           | O(1) if there are no hash collisions
                       |                  | Up to O(n) if there are hash collisions 
                       |                  | O(n) when hash is the same for any key
                       |                  |     
Insertion time         | log(n)+rebalance | Same as search
                       |                  | 
Deletion time          | log(n)+rebalance | Same as search
                       |                  | 
needs comparators      | only operator <  | only operator ==
                       |                  |
needs hash function    | no               | yes
                       |                  |
common use case        | when good hash is| In most other cases. 
                       | not possible or  | 
                       | too slow. Or when|
                       | order is required| 

У яких випадках воно потрапляло б до O (n)?

якщо у вас така погана хеш-функція, яка видає однакове хеш-значення для всіх вхідних штрингів (тобто викликає зіткнення) ...

Який контейнер я мав вибрати, карту чи unordered_map?

Це завжди питання вимог та виду / обсягу даних, якими ви володієте.

Коли карта отримує більш ефективний час, ніж unordered_map?

Це просто різні структури. Для використання одного з них вам краще задуматися, залежно від типових випадків використання (враховуючи, які у вас дані та їх обсяг)

Чи є hppaen, коли n мало?

У випадку невеликого обсягу даних все залежить від конкретної реалізації STL ... Тому іноді навіть звичайний вектор / масив може бути швидшим, ніж асоціативні контейнери ...

Який контейнер я мав вибрати, карту чи unordered_map? unordered_map займає більше пам'яті, тому припустимо, що пам'ять не є проблемою, а проблема полягає в швидкості.

Профілюйте, а потім вирішіть. unordered_mapяк правило, швидше, але це залежить від випадку.

У яких випадках воно потрапляло б до O (n)?

Коли хешування не є добрим, і до тих самих бункерів призначається купа елементів.

Коли карта отримує більш ефективний час, ніж unordered_map? Чи буває це, коли n мало?

Можливо, ні, але сформулюйте це, якщо вам дійсно все одно. Наявність контейнера невеликого розміру буде вузьким місцем вашої програми здається надзвичайно малоймовірним. У будь-якому випадку, простий vectorлінійний пошук може бути швидшим у таких випадках.

Найголовніше при прийнятті рішення - це вимоги впорядкування та відсутність анулювання ітератора. Якщо вам потрібно будь-яке, вам доведеться скористатися map. В іншому випадку unordered_map.