Многие профилировщики такие. Вам нужно знать не где программа проводит время, а почему. Есть ссылки на динамический анализ кода?
ДОБАВЛЕНО: Вот как Я нахожу «узкие места» в своем коде. (Я ненавижу это слово.) Вот список причин, почему.
Совершенно естественно предположить, что для поиска «узких мест» вам нужно как-то провести много измерений. Это настолько естественно, что почти все профилировщики основаны на нем.
Собственно, найти и измерить - не одно и то же. Необходимы измерения, чтобы увидеть, изменилось ли то, что вы нашли (и исправили). Поиск того, что исправить, для меня больше похоже на отладку, чем на измерение.
Самый простой способ объяснить это - начать с бесконечного или почти бесконечного цикла. Как вы его нашли? Вы ставите его на паузу и смотрите на стопку, верно? потому что вы знаете, что проблема где-то в стеке. Вам нужно только один раз приостановить его, а затем вам нужно изучить код в стеке. Сделайте паузу несколько раз, если хотите убедиться, что нашли его.
Предположим, код занимает вдвое больше времени, чем необходимо. Это означает, что когда вы ставите его на паузу, с вероятностью 50% вы увидите, что он выполняет ненужные действия. Если вы остановите его и посмотрите 10 раз, вы поймаете его в действии примерно 5 раз. Фактически, как только вы видите, что он делает что-то, что вы можете оптимизировать всего на двух образцах, вы обнаруживаете «узкое место». Исправьте это, измерьте ускорение, покажите это и повторите.
Даже если ваша самая большая проблема не очень большая, этот метод со временем ее найдет. Кроме того, существует феномен увеличения, когда небольшие проблемы легче найти после того, как вы удалите более крупные. Это позволяет продолжать работу до тех пор, пока код не станет почти оптимальным.
P.S. После того, как вы это сделаете, все еще могут быть возможности для ускорения. Например, алгоритмы оптимизации могут зависеть от числовой устойчивости. Архитектура, управляемая сообщениями, может затруднить отслеживание того, почему выполняется код. В программном обеспечении реального времени проблемы с производительностью могут возникать лишь изредка, и их труднее отследить. Это требует большей сообразительности. Отказ от простого измерения этого не делает.
person
Mike Dunlavey
schedule
03.11.2010
