Анализ кода для эффективности?

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

Для небольших случаев я использовал простые таймеры в коде (системное время в конце действия - системное время в начале действия).

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

INSERTED: Давайте посмотрим на «статистическую значимость».

Предположим, где-то есть инструкция вызова функции. Вы не обязательно его видите - возможно, класс, или макрос, или компилятор вставили его. Рядом есть другие вызовы той же функции, но этот вызов находится в цикле или его аргументы таковы, что этот вызов может занять много времени. Фактически, столько времени, что если бы этот вызов мог занять нулевое время, то общее время выполнения сократилось бы на некоторую величину, скажем, на 90%. (Невозможно? Вовсе нет.) Может ли время определить это? Нет. Определит ли это график вызовов? Нет. Счетчик звонков определит это? Нет. Потому что проблема не на уровне функции, а на уровне инструкции вызова.

Каким-то образом программа случайно останавливается в определенный момент времени, и ее состояние проверяется. Остановится ли он за те 90% времени, которое можно было бы сэкономить, если бы инструкцию можно было «обнулить»? Конечно - с вероятностью 90%, и инструкция будет точно определена в стеке в ожидании завершения ее «работы».

Фактически, если вы остановите его случайным образом 20 раз, эта инструкция будет в стеке в среднем 18 раз со стандартным отклонением +/- 1,3 раза.

Является ли это статистически значимым? Вы держите пари.
Вам нужно было большое количество образцов? Вы держите пари, что нет.

Предположим, процентное соотношение невелико, например, 10% или 5%. Применяется тот же принцип.

Фактически, независимо от того, сколько образцов взято, любая инструкция, которая относится к> 1 выборке, является статистически значимой и является «горячей точкой», «узким местом» или чем угодно. чтобы назвать это. Если бы вы могли удалить его, уменьшить или как-то уменьшить, это значительно сэкономит время. (Некоторые вы не можете, например "call _main", но другие можете. Вам просто нужно их найти.)

Конечно мой код никогда не был бы таким глупым, не так ли? Что ж, докажи это .

Хорошо, теперь вернемся к истории. . .

ОРИГИНАЛЬНЫЙ ОТВЕТ: Я слышал о профайлерах давным-давно, и я подумал, что они, должно быть, довольно аккуратные, но у меня не было доступа к ним / к нему. Я работал над встроенным процессором (чипом Intel 8086), который, казалось, очень долго рисовал числа с плавающей точкой на экране дисплея. Ребята, занимающиеся аппаратным обеспечением, предложили предоставить из своего множества - добавить микросхемы таймера, чтобы я мог видеть, сколько времени занимает работа. Однако в один из выходных я запустил его с помощью внутрисхемного эмулятора Intel "Blue Box" и запустил. Пока он был медленным, я подумал: «Какого черта он делает?». Так что я просто остановил это, чтобы узнать. ПК был в библиотеке с плавающей запятой (чипа FP не было). Это не было сюрпризом, поскольку он рисовал числа с плавающей запятой, но я хотел узнать больше. Поэтому я (с трудом) читаю шестнадцатеричную память, чтобы следить за стеком вызовов. Угадай, что? Он находился в процессе взятия числа, которое нужно нарисовать, деления его на 10, преобразования в целое, преобразования обратно в число с плавающей запятой, вычитания и т. Д. только для того, чтобы нарисовать следующую цифру . Излишне говорить, что были более эффективные способы сделать , чем , что привело к ускорению примерно в 10 раз. Это было обнаружено с одним (1) образцом!

В другом случае на микросхеме 68K наблюдалась некоторая медлительность. Опять же, профилировщик был недоступен, но был доступен отладчик adb, поэтому, пока он работал медленно, я несколько раз останавливал его. Компьютер был в математической библиотеке, фактически в 32-битной программе умножения целых чисел. Просматривая стек, я нашел этот код:

struct {...} a[...];

int i;
for (i = 0; i < ...; ++i){ ... a[i] ... }

Там нет вызова умножения - что происходит? Оказывается, для a [i] компилятор должен умножить i на размер элемента массива. Поскольку i имеет 32 бита (в этом компиляторе), он генерирует вызов 32-битной подпрограммы умножения, и стек определяет эту инструкцию вызова. Объявив i как short , скорость цикла утроилась!

Что? в чем дело? Если вы берете образцы в случайное время, пока программа работает медленно, ПК скажет вам, что он делает, но стек вызовов сообщит вам , почему , и приведет вас прямо к проблеме. Теперь, если проблема не является действительно серьезной, вам может потребоваться взять несколько образцов. Любое утверждение, которое появляется в> 1 образце, вызывает подозрение. Заметьте, он точно определяет операторов , инструкций даже, а не большие фрагменты кода, такие как функции. Этот метод может быть «быстрым и грязным», но он очень эффективен.

ДОБАВЛЕНО: Если вы будете делать это неоднократно, вы можете решать проблему за проблемой в одном и том же программном обеспечении. Например, если вы получили ускорение в 3 раза, небольшие проблемы с производительностью, которые раньше могли быть незначительными, теперь потребляют в 3 раза больше оставшегося времени. Это значительно упрощает попадание сэмплов в них. Возможно, вам придется добавить временный внешний цикл, чтобы он работал достаточно долго для выборки. Таким образом, я наблюдал усложненные коэффициенты ускорения более чем в 40 раз .

Я использую Valgrind и его инструмент Callgrind. Это отличный инструмент. Valgrind - это, по сути, виртуальная машина:

Valgrind, по сути, виртуальная машина, использующая точно в срок (JIT) методы компиляции, включая динамическая перекомпиляция. Ничего из исходная программа когда-либо запускается непосредственно на главном процессоре. Вместо этого Valgrind сначала переводит программу во временную, более простую форму называется промежуточным представлением (IR), который не зависит от процессора, Форма на основе SSA. После преобразования инструмент (см. ниже) можно делать бесплатно какие бы преобразования он ни хотел на IR, прежде чем Valgrind переведет IR обратно в машинный код и позволяет хост-процессор запускает его. Даже если он может использовать динамический перевод (что есть, хост и целевой процессоры от разных архитектур), это нет. Valgrind перекомпилирует двоичный файл код для запуска на хосте и таргетинге (или смоделированы) CPU того же

Callgrind - это профилировщик, построенный на этом. Главное преимущество в том, что вам не нужно запускать приложение часами, чтобы получить надежный результат. Достаточно нескольких секунд, потому что Callgrind - это профилировщик без зондирования ,

Другой инструмент, построенный на Valgrind, - Massif. Я использую его для профилирования использования памяти кучи. Он отлично работает, он дает вам снимки использования памяти - подробную информацию, ЧТО занимает КАКОЙ процент памяти и КТО поместил его туда.

Еще один инструмент Valgrind - DRD (и Helgrind). Я использую их для отслеживания мертвых блокировок и гонок данных в моем коде, а также для отслеживания злоупотреблений API потоков.

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

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

Вопрос неоднозначный. Эффективен с точки зрения времени выполнения или памяти? Контекст, в котором выполняется конкретный фрагмент кода, архитектура приложения и данные, которые могут быть переданы в него, также являются факторами.

Кстати, кто-то упомянул Purify; есть также его родственный продукт Quantify.

Я слышал добрые слова о Yourkit для профилирования Java. Для веб-сайтов я пробовал JMeter , который имеет базовые функции для простого параметризованного профилирования.

Для .NET я бы рекомендовал NDepend .

Я использую инструменты для этой работы. В противном случае мне было довольно сложно сделать это своими руками ... (ну, это мое мнение, на самом деле я никогда не пробовал)

В Linux я использую Valgrind , который поставляется с некоторыми полезными инструментами для профилирования ваш код. Что касается домашней страницы Valgrind:

Она работает на следующих платформах: X86 / Linux, AMD64 / Linux, PPC32 / Linux, PPC64 / Linux.

.. и это бесплатно (как в бесплатном пиве) и с открытым исходным кодом .

Хотя я нечасто их использовал, на другой платформе вы можете использовать Purify / Quantify (продукты IBM). Это коммерческие инструменты. Как сообщил об этом Уилл,