Как сделать профилирование настенных часов с помощью dtrace? Или, как подсчитать не запущенные процессы с помощью провайдера профилей?

Это заставляет меня задаться вопросом: можно ли предположить, что запрошенная частота дискретизации profile-n соблюдается?

В Solaris это не гарантируется: в некоторых старых аппаратных средствах отсутствует необходимая поддержка прерываний произвольного разрешения на основе таймера. Я бы предположил, что такое же теоретическое ограничение применимо и к DTrace OS X.

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

bash-3.2# cat test.d
uint64_t last;

profile-1500
/cpu == 0/
{
    now = timestamp;
    @ = lquantize(now - last, 500000, 800000, 30000);
    last = now;
}   

tick-1
/i++ == 10/
{
    exit(0);
}
bash-3.2# dtrace -qs test.d


           value  ------------- Distribution ------------- count    
          560000 |                                         0        
          590000 |@@@                                      1041     
          620000 |@@@@@@@@@@                               4288     
          650000 |@@@@@@@@@@@@@@                           5680     
          680000 |@@@@@@@@@@                               3999     
          710000 |@@@@                                     1451     
          740000 |                                         0        
          770000 |                                         0        
       >= 800000 |                                         1        

bash-3.2# 

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

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

pid$target:mylib:myfunc:entry
/!self->depth/
{
    self->depth = ustackdepth;      /* beware recursion */
    self->start_time = timestamp;   /* for relative wall time calculations */
    self->start_vtime = vtimestamp; /* CPU time */      
}

pid$target:mylib:myfunc:return
/ustackdepth == self->depth/
{
    printf("%d ms (real) %d ms (CPU)\n",
        (timestamp - self->start_time) / 1000000,
        (vtimestamp - self->start_vtime) / 1000000);
    self->depth = 0;
}   

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

Вполне возможно выполнить подобное упражнение для всех функций в вашей библиотеке, хотя устранение ложных результатов от рекурсии и оптимизации хвостовых вызовов может оказаться весьма обременительной задачей. Чтобы быть более полезным, вы, вероятно, также захотите исключить из стоимости функции время, затрачиваемое на вызов стека; это делает работу еще более сложной (но не невозможной). Таким образом, вооружившись указанными выше средствами для создания объективного эталона, я был бы более склонен придерживаться подхода профилирования, возможно, что-то вроде

# cat sample.d 
profile-997
/pid == $target && arg1 >= $1 && arg1 < $2/
{
    @[ufunc(arg1)] = count();
}

END
{
    trunc(@,5);
    exit(0);
}
#

Это фиксирует пять наиболее часто встречающихся функций в данной области памяти. Например (и используя pmap в Solaris для поиска libc),

# dtrace -qs sample.d -p `pgrep -n firefox` 0xfc090000 0xfc200000
^C

  libc.so.1`mutex_lock_impl                                        35
  libc.so.1`clear_lockbyte                                         46
  libc.so.1`gettimeofday                                           71
  libc.so.1`memset                                                 73
  libc.so.1`memcpy                                                170
# 

Это оказывается довольно хорошей иллюстрацией преимущества выборки: memcpy() и memset() кодируются вручную на ассемблере --- т. е. мы обнаруживаем, что самые трудоемкие функции уже оптимизированы.