Как измерять время выполнения программ в Linux с помощью time

Кратко: команда time в Linux измеряет три значения — real (стенсовое время), user (время в пользовательском пространстве) и sys (время в ядре). Чтобы получить корректные выводы, сочетайте многократные прогоны, сброс кешей при необходимости и простую автоматизацию для усреднения результатов.

Быстрые ссылки

• Timing Linux Programs

• The Linux time Tool

• Using time For Performance Measuring

• Using time For Code Optimization

• Wrapping up

Зачем измерять время выполнения

Измерения времени помогают понять, где тратится ресурс системы: на ожидание ввода-вывода, на вычисления в пользовательском коде или на работу внутри ядра. Это важно для тестирования производительности, оптимизации скриптов и принятия архитектурных решений. Одно предложение-определение: real — реальное (стенсовое) время, user — CPU время в режиме пользователя, sys — CPU время в режиме ядра.

Как работает команда time

Команда time возвращает три основных значения:

• real — общее прошедшее время с момента запуска до завершения процесса, то что обычно называют wall clock time;
• user — суммарное CPU время, потраченное в пользовательском пространстве процессом и его потомками;
• sys — суммарное CPU время, потраченное в режиме ядра (в системных вызовах) процессом и его потомками.

Важно: user и sys отражают только активно используемое CPU время. Если процесс ждет ввода-вывода или блокируется, эти периоды не учитываются в user/sys, но включаются в real. Поэтому часто user + sys < real.

Пример простого измерения сна:

time sleep 1

При запуске вы увидите, что real примерно равен 1 секунде, а user и sys почти нулевые, так как команда sleep не нагружает CPU.

Поведение при очень коротких прогонах

Когда процесс выполняется очень быстро, измерения могут быть неточными. В таких случаях процент использования CPU или некоторые поля могут показываться как 0 или как вопросительный знак. Рекомендуется прогонять быстрые команды многократно и усреднять результаты.

Использование time для проверки кеширования и ввода-вывода

Одно из практических применений — проверить, влияет ли файловый кеш на производительность. Пример: сканирование каталога /usr, где может быть сотни тысяч файлов.

cd /usr

time find . >/dev/null 2>&1

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

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

cd /usr

time find . >/dev/null 2>&1

Комментарий: первая команда очищает pagecache, dentries и inode кеши. После очистки вы обычно увидите увеличение real времени первого прогона и заметное ускорение последующих запусков за счет работы кеша.

Пример: измерение скорости парсинга выводов ps с помощью awk и sed

Для сравнения двух способов извлечения второго столбца из вывода ps можно выполнить многократные прогоны и измерить суммарное время:

time for ((i=1;i<=1000;i++)); do ps -ef | awk '{print $2}' >/dev/null 2>&1; done

time for ((i=1;i<=1000;i++)); do ps -ef | sed 's|^[^ ]+[ \t]+||;s|[ \t].*||' >/dev/null 2>&1; done

Наблюдение: в примере sed оказался немного быстрее по real времени. Такие сравнения помогают выбрать решение с меньшим стенсовым временем или меньшей нагрузкой на CPU.

Когда измерения вводят в заблуждение

• Нагрузочные факторы окружения: другие процессы могут потреблять CPU и I/O, искажающие результаты.
• Кеширование: первый прогон может быть существенно медленнее, чем последующие.
• Параллелизм и многопоточность: время real может быть меньше суммарного CPU времени для параллельных задач на многопроцессорной системе.
• Планировщик и приоритеты процесса: nice, cgroups, cpuset и другие механизмы влияют на наблюдаемые значения.

Важно: проверяйте условия повторно и фиксируйте состояние системы перед прогоном.

Мини‑методология для корректного измерения

1. Определите цель измерения: оптимизировать real, уменьшить CPU или снизить I/O.
2. Подготовьте окружение: остановите ненужные сервисы или используйте изолированный тестовый стенд.
3. Прогоните команду несколько раз, например 10–100 повторами для быстрых операций и 3–10 для медленных.
4. Сбросьте кеши, если цель — измерить работу с диска, и задокументируйте это.
5. Усредните значения real/user/sys и оцените разброс.
6. При изменении реализации сравнивайте оба решения в одном и том же окружении.

Скрипт шаблон для многократных прогонов и подсчёта среднего

Ниже простой bash скрипт, который выполняет команду N раз и вычисляет средние значения real/user/sys на основе вывода time в формате GNU time с ключом -f.

#!/usr/bin/env bash

N=50
COMMAND="ps -ef | awk '{print $2}' >/dev/null 2>&1"

sum_real=0
sum_user=0
sum_sys=0

for ((i=1;i<=N;i++)); do
  # GNU time required, формат: %e - real, %U - user, %S - sys
  out=$( /usr/bin/time -f "%e %U %S" bash -c "$COMMAND" 2>&1 >/dev/null )
  read -r r u s <<< "$out"
  sum_real=$(awk "BEGIN{print $sum_real+$r}")
  sum_user=$(awk "BEGIN{print $sum_user+$u}")
  sum_sys=$(awk "BEGIN{print $sum_sys+$s}")
done

echo "avg_real="$(awk "BEGIN{print $sum_real/$N}")
echo "avg_user="$(awk "BEGIN{print $sum_user/$N}")
echo "avg_sys="$(awk "BEGIN{print $sum_sys/$N}")

Примечание: на некоторых системах системная утилита time не поддерживает ключ -f, тогда используйте команду /usr/bin/time или установите пакет time (GNU time).

Чек-листы по ролям

Разработчик

• Измерить узкие места локально
• Сравнить алгоритмы и библиотеки
• Использовать многократные прогоны и усреднение

Системный администратор

• Оценить влияние сервисов на окружение теста
• Контролировать кеши и параметры ядра
• Использовать изолированные ноды для честных замеров

DevOps / SRE

• Автоматизировать тесты в CI с фиксированным окружением
• Учитывать нагрузки соседних контейнеров или VMs
• Задавать SLI/SLO для времени отклика там, где это применимо

Эвристики и ментальные модели

• Если user + sys значительно меньше real, то большая часть времени уходит на ожидание (I/O, sleep, блокировки).
• Если user >> sys, проблема в вычислениях в пользовательском коде.
• Если sys >> user, много времени уходит в системные вызовы: частые операции ввода-вывода, сетевые операции, переключения контекста.
• Для коротких команд всегда используйте усреднение и более длительные циклы прогона.

Сравнение подходов: когда использовать что

Примеры, когда time не даёт полной картины

• Параллельные распределённые задачи: время real одной ноды не отражает суммарных затрат всей задачи.
• Сценарии с интенсивной работой сети: сетевые задержки и очереди могут доминировать, и локальные CPU-метрики будут недостаточны.
• Приложения с JIT или динамической оптимизацией: первый прогон может быть медленнее из-за компиляции.

Критерии приёмки

• Показатели измерены не менее трех раз и имеют коэффициент вариации в допустимых пределах для задачи.
• Описано состояние окружения (сброшены кеши или нет, уровень нагрузки на хосте).
• Для оптимизаций проведено A/B сравнение в одинаковых условиях.

Глоссарий (одна строка каждый)

real — стенсовое время от запуска до завершения процесса. user — суммарное время работы процесса на CPU в пользовательском пространстве. sys — суммарное время работы процесса на CPU в режиме ядра.

Заключение

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

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

Краткое резюме

• time показывает real, user и sys
• user и sys суммируются как использованное CPU время
• real включает периоды ожидания и блокировки
• для честных замеров используйте повторные прогоны и фиксируйте состояние кешей

Ресурсы для чтения

• man time
• Документы по perf и strace