Вопрос 1: Какие инструменты вы используете для профилирования кода (профилирование, а не тестирование производительности)?
Q2: Как долго вы позволяете коду работать (статистика: сколько временных шагов)?
Q3: Насколько велики дела (если дело помещается в кеше, решатель работает на несколько порядков быстрее, но тогда я пропущу процессы, связанные с памятью)?
Вот пример того, как я это делаю.
Я отделяю бенчмаркинг (видя, сколько времени это занимает) от профилирования (определяя, как сделать это быстрее). Не важно, чтобы профилировщик был быстрым. Важно, чтобы он говорил вам, что исправить.
Мне даже не нравится слово «профилирование», потому что оно вызывает в изображении нечто похожее на гистограмму, где для каждой подпрограммы есть полоса затрат, или «узкое место», потому что это означает, что в коде есть только небольшое место, которое необходимо фиксированный. Обе эти вещи подразумевают какое-то время и статистику, для которой, как вы полагаете, важна точность. Не стоит отказываться от понимания точности времени.
Использование метода I является случайной паузой, и есть полный пример и слайд - шоу здесь . Часть мировоззрения «профилировщик-узкое место» заключается в том, что если вы ничего не находите, ничего не найдете, а если вы что-то находите и получаете определенный процент ускорения, вы объявляете победу и выходите. Поклонники профилировщиков почти никогда не говорят, насколько они ускоряются, а реклама показывает только искусственно созданные проблемы, которые легко найти. Случайная пауза находит проблемы, простые они или сложные. Затем решение одной проблемы обнажает другие, поэтому процесс можно повторить, чтобы ускорить процесс.
На моем опыте из многочисленных примеров, вот как это происходит: я могу найти одну проблему (путем случайной паузы) и исправить ее, получив ускорение на несколько процентов, скажем, на 30% или в 1,3 раза. Затем я могу сделать это снова, найти другую проблему и исправить ее, получив еще одно ускорение, может быть, менее 30%, а может и больше. Затем я могу сделать это снова, несколько раз, пока я действительно не смогу найти что-то еще, чтобы исправить. Конечным фактором ускорения является результат работы отдельных факторов, и он может быть удивительно большим - в некоторых случаях на несколько порядков.
ВСТАВЛЕНО: Просто чтобы проиллюстрировать этот последний момент. Там есть подробный пример здесь , с слайд - шоу и все файлы, показывая , как было достигнуто убыстрение 730X в ряде проблемных удалений. Первая версия заняла 2700 микросекунд на единицу работы. Проблема A была удалена, в результате чего время сократилось до 1800, а процент оставшихся проблем увеличился в 1,5 раза (2700/1800). Затем Б был удален. Этот процесс продолжался в течение шести итераций, что привело к ускорению почти на 3 порядка. Но метод профилирования должен быть действительно эффективным, потому что, если какая-либо из этих проблем не будет найдена, то есть если вы достигнете точки, когда вы ошибочно думаете, что больше ничего не может быть сделано, процесс останавливается.
ВСТАВЛЕНО: Проще говоря, вот график общего фактора ускорения, поскольку устраняются последующие проблемы:
Так что для Q1 для бенчмаркинга достаточно простого таймера. Для «профилирования» я использую случайную паузу.
Q2: я даю ему достаточно рабочей нагрузки (или просто зацикливаю), чтобы он работал достаточно долго, чтобы сделать паузу.
Q3: Во что бы то ни стало, создайте реально большую рабочую нагрузку, чтобы не пропустить проблемы с кэшем. Они будут отображаться как примеры в коде, выполняющие выборку из памяти.