Профилировщик для FPC

[@!!ex]

Подскажите профилировщик для программ написанных на FPC.
На дельфе пользовался AQTime, очень удобно, но платно, и FPC Не дружит.
Есть ли что-то подобное для FPC? Желательно фрищное и под виндой.
Спасибо.

[Cheb]

Код: Выделить всё

var
BottleNeckCounter1, BottleNeckCounter2: int64;

Остальное - 4 inc файла, вставляемых где надо когда надо:

старт
BottleNeckCounter1:=0;
BottleNeckCounter2:=0;
Asm
  pushf
  push eax
  push edx
  rdtsc
  sub [BottleNeckCounter1], eax;
  sbb [BottleNeckCounter1 + 4], edx;
  pop edx
  pop eax
  popf
End;

начало измеряемого участка
Asm
  pushf
  push edx
  push eax
  rdtsc
  sub [BottleNeckCounter2], eax;
  sbb [BottleNeckCounter2 + 4], edx;
  pop eax
  pop edx
  popf
End;

конец измеряемого участка
Asm
  pushf
  push edx
  push eax
  rdtsc
  add [BottleNeckCounter2], eax;
  adc [BottleNeckCounter2 + 4], edx;
  pop eax
  pop edx
  popf
End;

стоп
Asm
  pushf
  push eax
  push edx
  rdtsc
  add [BottleNeckCounter1], eax;
  adc [BottleNeckCounter1 + 4], edx;
  pop edx
  pop eax
  popf
End;
WriteLn('Bottleneck test result: ', round(100.0 * (BottleNeckCounter2 / BottleNeckCounter1)));

[Bupyc]

Для этих же целей можно использовать API функцию GetTickCount

Код: Выделить всё

procedure SomeProc();
var
  tickCount : Cardinal;

begin
tickCount := GetTickCount();

// Start doing something

.........................................

// Stop doing something

tickCount := GetTickCount() - tickCount;

// в tickCount имеем приблизительное время
// выполнения кода в системных тиках (они же миллисекунды)

end;


[*vmr]

Cheb
Конечно свой cycle-counter это здорово, но увы для профилирования сложных многопоточных программ он не подходит


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

Вот подумываю написать свой, юзая вот это http://www.dtf.ru/articles/read.php?id=40520

[Cheb]

Для этих же целей можно использовать API функцию GetTickCount

Ничего более безграмотного сказать было нельзя.

А). Время вызова этой функции напрочь собьёт все результаты (в отличие от моего варианта, практически не влияющего на результат измерений).
Б). Погрешность этой функции - в районе 20мс, или 20 000 микросекунд (в отличие от моего варианта, считающего тактовые циклы процессора - т.е. с погрешностью около половины той же микросекунды).

// в tickCount имеем приблизительное время
// выполнения кода в системных тиках (они же миллисекунды)

Это *Если* использовать при старте программы ф-ю TimeBeginPeriod(1). Иначе округляет до ближайших примерно 20 милисекунд.

[@!!ex]

Cheb, не вариант. Потому что:
1) 40 модулей, 400 классов, 50000 строк. И надо найти саые узкие места... один тест занимает около 10 минут, чтобы свести к минимум влияение локальных всплесков и получить максимально верное значение... да я до второго приешствия искать узкие места буду.
2) Узкие места надо статистически искать. Один замер ничего не даст.

Bupyc
Тем более не вариант. GetTickCount дает точность в 16 мс. У меня весь расчет занимает 12-15мс, а узкие места - меньше 1мс. Их и не найдешь используя GTC.

*vmr
ТОже подумываю о написании своего профайлера.
Вечером поговорю с братом. У него есть наработки:
Парсится исходник, строится список функций и процедур, в указанные процедуры внедряется код для расчета, компилируется, запускается, далее получаем файл и он уже в просмоторщике просматривается.



Вобщем я понял, акромя gproof'a нет никаких профайлеров. Очень жаль.... Придется исправлять эту ситуацию.

[Cheb]

, но увы для профилирования сложных многопоточных программ он не подходит

В принципе, можно наверно использовать и для многопоточного - если каждый поток работает на отдельном ядре. Главное - чтобы в момент stop все внутренние бегин-энды были закрыты.

40 модулей, 400 классов, 50000 строк. И надо найти саые узкие места...

Ой, мама.
Хотя... Я с помощью этой штуки рекурсивный алгоритм с кучей ветвлений мерил - во это было весело, штук n-цать бегин-эндов в код понавтыкал. Но сработало.

[@!!ex]

Мда. я ступил, второй пункт моег сообщения не актуален.

Кстати, время ввыполнения кода замера роли не играет.
Просто при запуске надо посчитать сколько времени это занимает, и вычесть из результата расчета.

[Cheb]

Мой метод даёт результат сразу в процентах.

Просто при запуске надо посчитать сколько времени это занимает, и вычесть из результата расчета.

А вот это уже вряд ли: оптимизатор склеит его воедино с с измеряемым кодом, и как это повлияет на скорость - сказать не может никто.

[Brainenjii]

http://www.freepascal.ru/forum/viewtopic.php?t=3252 - не то?

[@!!ex]

40 модулей, 400 классов, 50000 строк. И надо найти саые узкие места...

Ой, мама.
Хотя... Я с помощью этой штуки рекурсивный алгоритм с кучей ветвлений мерил - во это было весело, штук n-цать бегин-эндов в код понавтыкал. Но сработало.

Я соврал. модулей 96, строк кода всего 40000, а классов х.з., но думаю сотни 4 должно набраться.

Мой метод даёт результат сразу в процентах.

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

[@!!ex]

Brainenjii
Может и то! Спасибо! Главное, чтобы под виндой работало.... Портирование под Линукс мы начнем только на следующей недели...

[@!!ex]

А. Блин. ступил. как же оно будет работать под виндой, если это KDEшная приблуда? (

[*vmr]

Cheb
Не ожидал такое от тебя услышать.....

>А). Время вызова этой функции напрочь собьёт все результаты (в отличие от моего варианта, практически не влияющего на результат измерений).
Эта функция все-то навсего возвращает значение системной переменой
Время ее выполниения -- ничтожно

>Погрешность этой функции - в районе 20мс, или 20 000 микросекунд
Точно 16 мс для Win2k, XP & 2003Server
Оно равняется интервалу "тика" системного таймера, который по дефолту настроен на 16 мс = 1 квант времени для этих операционок
Длительность этого кванта времени можно менять ф-ей TimeBeginPeriod

Для полного просветления читать "То, что вам никто не говорил о многозадачности в Windows"

А вообще замер колчества тиков проца - стремное дело:
* процессоры имеют привычку менять свою частоту (Cool&Quiet например)
* Операционка имеет привычку перекидывать потоки с ядра на ядро. А у каждого ядра может быть свой счетчик тиков....

[@!!ex]

*vmr
Проблема с частотой процессора решается с помощью утилит это дело контролирующих.

ИМХо GTC не годится для расчетов. Точность слишщком низкая.