profiler: как правильно искать узкие места в приложении?

[belugin]

Встроенный профайлер замедляет быстродействие примерно раз в 30.

При этом он это делает только для кода, который выполняется аксаптой, а SQL остается как есть.

Таким образом, в результате картина узких мест сильно искажена.

кто-нибудь решал задачи измерения быстродействия и профилирования и каким образом?

Я сделал тупую имплементацию профилировщика, но он тоже тормозит отчего следующий вопрос:
Может быть можно написать внешний компонент, например, DLL и вызывать её?
Каким образом с ней проще и быстрее общаться? (COM, DLLFunction)

[macklakov]

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

[belugin]

а что за макросы?

[Maxim Gorbunov]

Полагаю, имеются ввиду #profileBegin, #profileEnd и #profileFlush

[glibs]

А прикладную проблему то можно озвучить?

На моей не очень большой, так сказать, практике когда дело доходит до профайлера, то задача сводится к поиску неоптимально написанного кода. Как правило, это неправильно выбранный алгоритм обработки. Ну, например, очень-очень большое количество мелочных запросов к базе, которые не отловишь трассировкой SQL-запросов, порожденные каким-то циклом (но можно было, например, организовать кеш или просто сменить алгоритм).

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

М.б. вы сможете другой пример привести?

[belugin]

Вобщем задача специфическая. Пока пытаюсь понять, где порылись тормоза.

В целом: есть бетч джоб, который по хитрому алгоритму производит пере распределение потребностей между складами (ReqPo.qty = newQty; ReqPo.update())

После чего происходит их обработка классом ReqTransPoMarkFirm

Сейчас больше половины времени жрется на ReqPo.update(). Требуется выяснить насколько изменится быстродействие если в апдейте останется только то, что надо.

В качестве очень грубого приближения заменяем ReqPo.update на ReqPo.doUpdate.

время на обновления записи схлопывается в нуль, но при этом ReqTransPoMarkFirm.run сильно замедляется. вопрос - почему?

Точность до миллисекунды не нужна, нужно чтоб хотябы соотношения времен были нормальные.