Что такое скорость алгоритма

Скорость алгоритма отвечает на простой вопрос: что будет со временем работы, если данных станет больше. Если массив вырос со 100 элементов до 10 000, важны не только текущие миллисекунды. Важно понять, как быстро растет объем работы.

Для этого используют асимптотическую оценку, чаще всего Big O. Она убирает детали вроде конкретного процессора, версии браузера и мелких констант. Так вам проще сравнить общий характер роста.

Короткая формулировка для интервью:

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

Big O не обещает конкретное время выполнения. Оно показывает, как быстро растет работа алгоритма.

Например, один проход по массиву это O(n). Если элементов стало в 10 раз больше, работы тоже примерно станет в 10 раз больше. Два вложенных прохода по одному массиву часто дают O(n^2). Если данных стало в 10 раз больше, сравнений может стать примерно в 100 раз больше.

Частая фронтенд-ловушка: для каждого элемента одного списка искать связанный элемент во втором списке через find. На маленьких данных это выглядит нормально. При росте списков такой код превращается в много лишних сравнений.

Плохой вариант, если списки большие:

const rows = users.map((user) => ({
  ...user,
  order: orders.find((order) => order.userId === user.id),
}));

Здесь для каждого пользователя мы снова проходим по заказам. Если пользователей и заказов много, получаем примерно O(n * m). В React-компоненте такой код особенно опасен в рендере: каждый новый рендер снова запускает дорогой поиск, из-за этого ввод, раскрытие списка или скролл могут начать лагать.

Более безопасный вариант:

const orderByUserId = useMemo(
  () => new Map(orders.map((order) => [order.userId, order])),
  [orders]
);

const rows = useMemo(
  () => users.map((user) => ({
    ...user,
    order: orderByUserId.get(user.id),
  })),
  [users, orderByUserId]
);

Мы строим индекс только при изменении заказов, а потом быстро берем заказ по ключу. Это требует дополнительной памяти. Зато такой подход часто убирает дорогой вложенный поиск и лишнюю работу при повторных рендерах. Если вычисление выполняется не в компоненте или данные маленькие, можно оставить более простой вариант и не усложнять код заранее.

Хороший ответ не должен звучать так, будто вы всегда выбираете самый сложный алгоритм. В продуктовой разработке важен баланс: размер данных, частота операции, читаемость, память и реальная проблема пользователя.

Если список из 20 элементов фильтруется один раз, простой код может быть лучшим выбором. Если список из 20 000 элементов фильтруется на каждый ввод в поле поиска, уже стоит думать про debounce, индексацию, серверный поиск, виртуализацию списка или Web Worker. Иначе пользователь получает задержку ввода, устаревший результат на экране или ощущение, что страница зависла.

Во фронтенде тяжелый синхронный код часто выполняется в главном потоке. Там же браузер обрабатывает клики, ввод, layout, paint и JavaScript. Если алгоритм долго работает, пользователь видит зависание, задержку ввода или рывки при скролле.

Поэтому практический вывод такой: оценивайте не только сложность функции, но и место вызова. Код внутри обработчика ввода, рендера или скролла опаснее, чем та же операция при редкой загрузке страницы.

На интервью покажите эту связь явно. Скажите, где запускается код, как часто он выполняется и что увидит пользователь, если операция станет дорогой.