Big O часто обсуждают как теорию для собеседований. Но в реальной разработке это инструмент выбора структуры данных под конкретный профиль операций.

Когда речь про прикладной код, важно смотреть не на одну операцию, а на весь профиль нагрузки 👇

❗️ Что доминирует: чтение, вставка, удаление или обход. ❗️ Есть ли требования к порядку элементов. ❗️ Нужны ли ключи не-строки (тогда чаще Map, а не Object). ❗️ Нужна ли уникальность значений (тогда Set, а не ручная дедупликация).

Практически это обычно выглядит так 👇

❗️ Array удобен как последовательность, но проверка существования через includes() на больших объёмах становится O(n). ❗️ Set даёт быстрый has() в среднем O(1), если задача - membership/уникальность. ❗️ Object удобен как простая запись, но для частых операций над ключами и предсказуемого API часто лучше Map. ❗️ Map не заменяет Set, а Set не заменяет Map: это разные модели данных и разные сценарии.

Самая частая ошибка, на мой взгляд, выбирать структуру «по привычке». Вторая ошибка - смотреть только на асимптотику и игнорировать константы, форму данных и реальные размеры коллекций.

На малых объёмах разница может быть незаметной. На горячем пути та же разница становится критичной.

Инженерный подход простой 👇

❗️ Сначала описать операции и их частоты. ❗️ Затем выбрать структуру под доминирующие сценарии. ❗️ И в конце проверить всё на реальных данных, а не на синтетическом микро-бенчмарке в вакууме.

Производительность редко убивается одной «медленной функцией». Чаще её убивает систематически неверный выбор структуры данных в ключевом пути. #js