Горячая точка в информатике чаще всего определяется как область компьютерной программы , где происходит большая доля выполняемых инструкций или где тратится больше всего времени во время выполнения программы (это не обязательно одно и то же, поскольку некоторые инструкции выполняются быстрее других).
Если программа прерывается случайным образом, счетчик программ ( указатель на следующую инструкцию, которая должна быть выполнена) часто содержит адрес инструкции в определенном диапазоне, что может указывать на код, который нуждается в оптимизации, или даже на существование «жесткого» цикла ЦП . Этот простой метод может обнаружить часто используемые инструкции, хотя более сложные методы, такие как симуляторы набора инструкций или анализаторы производительности , достигают этого более точно и последовательно.
Специалист по информатике Дональд Кнут описал свою первую встречу с тем, что он называет траекторией прыжка, в интервью для журнала доктора Добба в 1996 году, сказав:
В 60-х кто-то придумал концепцию «трассировки перехода». Это был способ изменения машинного языка программы, чтобы она изменяла следующую ветвь или инструкцию перехода , чтобы сохранить управление, так что вы могли выполнять программу на довольно высокой скорости вместо того, чтобы интерпретировать каждую инструкцию по одной и записывать в файл только то, где программа отклонялась от последовательности. Обрабатывая этот файл, вы могли выяснить, где программа тратила большую часть своего времени. Поэтому в первый день, когда у нас работало это программное обеспечение, мы применили его к нашему компилятору Fortran, предоставленному, я полагаю, в те дни, Control Data Corporation . Мы обнаружили, что он тратит 87 процентов своего времени на чтение комментариев ! Причина была в том, что он переводил из одной кодовой системы в другую и в другую. [1]
Приведенный выше пример иллюстрирует, что эффективное обнаружение горячих точек часто является итеративным процессом и, возможно, таким, который следует выполнять всегда (вместо того, чтобы просто принять, что программа работает разумно). После устранения всей посторонней обработки (например, просто удалив все встроенные комментарии), новый анализ времени выполнения точнее обнаружит «подлинные» горячие точки в переводе. Если бы обнаружение горячих точек вообще не проводилось, программа вполне могла бы потреблять гораздо больше ресурсов, чем необходимо, возможно, в течение многих лет на многочисленных машинах, и никто никогда не осознавал этого в полной мере.
Симулятор набора инструкций может использоваться для подсчета каждого времени выполнения определенной инструкции и последующего создания либо отображения на экране, либо распечатанного списка программ (с подсчетами и/или процентами от общей длины пути инструкций ), либо отдельного отчета, показывающего, где именно было выполнено наибольшее количество инструкций. Это дает только относительное представление о горячих точках (с точки зрения шага инструкции), поскольку большинство инструкций имеют разное время выполнения на многих машинах. Тем не менее, он дает меру часто используемого кода, которая сама по себе весьма полезна при настройке алгоритма.