Профилирование (возможно, связанного с I/O) процесса для уменьшения латентности

Ответ 1

Используйте этот метод.

Это довольно просто и эффективно, чтобы выявить возможности оптимизации, независимо от того, находятся ли они в коде, связанном с ЦП или IO.

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

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

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

Во-первых, я предполагаю, что он не блокирует ручной сигнал прерывания отладчику, потому что в противном случае у вас не было бы способа остановить бесконечный цикл. Во-вторых, я бы обернул цикл 10, 100 или 1000 раз вокруг рассматриваемой процедуры, поэтому он делает это достаточно долго, чтобы вручную прерываться.

Теперь предположим, что он тратит часть времени на ввод-вывод, как 50%. Затем, когда вы прерываете его, у вас есть 50% шанс поймать его в I/O. Поэтому, если вы поймаете его в I/O, который скажет вам стек вызовов, вы также можете увидеть подробные сведения о том, откуда запрашивается ввод-вывод и почему.

Он покажет вам, что происходит, что почти наверняка удивительно. Если вы видите, что он делает что-то всего на двух (2) образцах, которые можно найти для устранения, то вы получите значительное ускорение. Фактически, если вы устраните эту активность, вы заранее не знаете, сколько времени вы сэкономите, но в среднем вы можете рассчитывать сохранить долю F = (s + 1)/(n + 2), где n - это общее количество образцов, которые вы взяли, и s - количество образцов, которые показали активность. (Правило преемственности) Например, если вы взяли 4 образца стека и увидели активность на 2 из них, в среднем это спасло бы вас F = 3/6 = 1/2, что соответствует коэффициенту ускорения 1/(1-F) или 2.

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

Тогда, конечно, вы удалите внешний цикл и "получите наличные" все ускорения, которые вы получили.

Если вам интересно, как это отличается от профилирования, то, что, тщательно изучая каждый образец стека и, возможно, связанные данные, вы можете распознавать действия, которые вы можете удалить, если, если все, что у вас есть, есть измерения, вы остаетесь пытаясь понять, что происходит. Фактическое количество времени, которое вы сохраняете, это то, что есть, независимо от каких-либо измерений. Важно найти проблему. Независимо от того, насколько точно профилировщик может его измерить, если вы не можете его найти, вы не выигрываете. Эти страницы полны людей, которые говорят, что они не понимают, что их профайлер говорит им, или, похоже, говорят, что нечего исправить, что они слишком охотно принимают. Это случай с розовыми тонированными стеклами.

Подробнее обо всем этом.

Ответ 2

Для приложений, связанных с I/O, вы можете использовать опцию --collect-systime=yes для callgrind.

Это собирает время, затрачиваемое на системные вызовы (в миллисекундах). Поэтому, если вы считаете, что у вас есть узкое место ввода-вывода, вы можете использовать эту статистику для ее идентификации.

Ответ 3

Todo: проверьте 'perf' (снова)

Ответ 4

• вилка()
• execxxx (проверяемый процесс)
• в родительском:
  • (в цикле) периодически вызывают:
  • getrusage (RUSAGE_CHILDREN,...)

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