В Linux и Mac OS X я могу запустить команду из интерфейса командной строки, используя команду time (не время встроенной команды оболочки bash), и получить не только истекшее время выполнения от начала до конца, но и многие другие. и другая статистика. Например, в Mac OS X:
% /usr/bin/time -lp /usr/bin/wc PS1-01.m4v
6166365 46283357 1532034853 PS1-01.m4v
real 27.09
user 24.65
sys 1.17
1433600 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
361 page reclaims
1 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
0 signals received
4 voluntary context switches
21604 involuntary context switches
В Ubuntu 10.4 "/ usr / bin / time -v" выдает похожий, но не идентичный вывод. Это, безусловно, достаточно хорошо для моих целей.
Я также могу получить аналогичные результаты на Windows XP + Cygwin. На Cygwin, если измеряемая команда является «двоичным файлом Cygwin», она работает так, как я хочу. Но если измеряемая команда является , а не «двоичным файлом Cygwin» (например, в моем случае я запускаю виртуальную машину Java из командной строки, указывая файл класса программы для запуска в командной строке), тогда кажется, что команда time измеряет статистику для «скрытого» процесса оболочки, а не для двоичного файла Windows. По крайней мере, это имело бы смысл, учитывая то, что я видел. Мое убеждение, что это процесс оболочки, который измеряется, исходит из этого письма от человека, который тщательно исследовал этот вопрос несколько лет назад, и позже в той же ветке электронной почты разработчик Cygwin подтверждает свои выводы:
http://cygwin.ru/ml/cygwin/2001-09/msg00202.html
Больше всего меня интересует статистика, которая называется «максимальный размер резидентного набора» в Linux и Mac OS X (иногда сокращенно Max RSS или MRSS), но может называться «размером рабочего набора» в Windows. Еще один момент, который я хотел бы видеть, это процент времени, в течение которого каждое ядро процессора занято (или простаивает - я могу сделать 100-кратное самостоятельно) с отдельным измерением для каждого ядра в многоядерной системе. Было бы неплохо также использовать использованное пользователем и системное время ЦП, что соответствовало бы разбивке процессорного времени на ядро Windows и время выполнения пользовательского приложения, но было бы также неплохо объединить оба из них в одно число. Обратите внимание, что такие числа могут быть на больше , чем истекшее время настенных часов в многоядерной системе, если программа использует более одного параллельно.
Я видел другие упоминания о переполнении стека timeit.exe и timethis.exe. Похоже, они дают только прошедшее время, насколько я могу судить. Я думаю, что есть много инструментов, которые могут дать мне текущий «размер рабочего набора» процесса, но только те, которые мне известны, показывают это число в окне графического интерфейса. Это действительно полезно для меня, только если я могу получить информацию, используя пакетный метод, потому что я хочу проводить тестирование производительности многих различных программ, запускаемых из CLI, по одной из сценариев за раз.