C/C++: Определение отрезка времени

Выкатываем в очередной раз release, и как водиться перед окончательной отправкой на PRO проверяем performance ( фу, сколько странных слов, но я предпочитаю называть это - проф сленг ). Итак вывод QA - не проходит по скорости - какого ... ведь только добавили проверку на количество свободной памяти. Ладно может действительно пара вычислений + цикл foreach по количеству worker'ов - слишком много? Ok, давайте будем проверять только раз в несколько секунд. Пару часов и стало только хуже? Да, как только такое возможно. Один из моих коллег подсказывает, что time - это системный вызов, много затрачивает времени .... хм давайте разберемся.

Сделаем небольшой тест, сколько времени занимает вызов time.

Запускаем:

$ gcc time.c -o time.out && time ./time.out
Tries 4294967295
real    0m13.988s
user    0m13.993s
sys     0m0.007s

Запускал на системе:

Intel Core-i5 3210M
DDR III 4GB

Итак:

$ python -c "print 13.988/4294967295"
3.25683504419e-09

Эх, а на рабочей машине было 2.85e-09, т.е. где-то 2-3 наносекунды ( знаю не самый точный результат, сюда еще входит вывод в консоль и запуск и т.д. и т.п.), по моим меркам, совсем немного, чтобы получить время и сделать вычитание двух чисел.

Но, можем ли мы быстрее, на ум приходит функция gettimeofday, сразу закрадываются сомнения в производительности, ну да ладно тестируем:

Запускаем:

$ gcc gtod.c -o gtod
$ time ./gtod
real    1m53.172s
user    1m53.213s
sys     0m0.061s

Да, совсем не фонтан ( правда я забыл вывести количество попыток, но ждать еще 2 минут не никакого желания ), итого:

$ python -c "print (1*60 + 53.172)/4294967295"
2.63499096097e-08

Приблизительно в 10 раз gettimeofday медленнее, чем time.

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

Напоследок, хотел привести реализации с использованием Rdtsc и HPET, но на часах давно уже за полночь и тянет ко сну, так что в другой раз.

Вот пару ссылок почитать:

Конец же истории с тестированием, таков, что на машине был запущен процесс tcpdump, который скидывал весь трафик на диск ( и это на виртуальной машине ), но и это не конец, оказывается на всех PRO машинах запушен tcpdump. Зачем, да для того чтобы если что случиться можно посмотреть трафик. Я не спорю цель благородная, но только это сравнимо с тем, что конструкторы пытаются спилить каждый грамм с болида формулы 1, а при старте к болиду цепляют прицеп от фуры с одной лишь только целью - запротоколировать возможные проблемы.

Закончился день тоже примечательно, получил screen shoot kdiff, на просьбу прислать diff с изменениями файла. Даа, и не лень было ему скриншот снимать, очень уж не хочется верить в то что, он не знает как пользоваться командами diff и patch.