По О-нотации она довольно эффективна (в среднем сложность константная), отнюдь на практике достаточно дорогая в некоторых ситуациях. Например, у меня в парсере обработка заголовков - это довольно интенсивная как запись, так и чтение, потому что значений у заголовка может быть несколько - приходится держать их всех в слайсе.
И парсер был довольно медленным. Профайлер показывал, что бОльшая часть времени уделяется операциям с хэшмапой. Поэтому я решил попробовать заменить ее просто на
[]string, где четный индекс всегда ключ, а нечетный - всегда значение заголовка. Теперь асимптотика стабильно линейная, что является регрессией. Но в абсолютных числах - в бенчмарках с большим количеством заголовков, он стал в среднем в два раза быстрее (но чем заголовков больше, тем больше и разрыв). Но почему так? Потому что при интенсивной записи, не очень интенсивном чтении и небольшом количестве ключей (лимит - 50 заголовков, в среднем 10-20), обычный перебор будет быстрее. Но тенденция сохраняется до 20-30 элементов, далее скорость начинает линейно отставать от в среднем константной у хэшмапы (но и с 50 элементами перебор не намного медленнее хэшмапы). Также заметную часть расходов удалось убрать за счет отсутствия операции очищения мапы.
Но в целом, обычный одномерный слайс строк просто-напросто более удачная структура данных по части абсолютной производительности для конкретного кейса¯\_(ツ)_/¯