?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Flag Next Entry
python profiling people
nyaload
_winnie
Кое-что меня шокирует в форумных python-people и документации по профайлингу.

It’s tempting to calculate mean and standard deviation from the result vector and report these. However, this is not very useful. In a typical case, the lowest value gives a lower bound for how fast your machine can run the given code snippet; higher values in the result vector are typically not caused by variability in Python’s speed, but by other processes interfering with your timing accuracy. So the min() of the result is probably the only number you should be interested in.

By default, timeit() temporarily turns off garbage collection during the timing. The advantage of this approach is that it makes independent timings more comparable.

И этот кусок документации втекает в головы людей, они им потом в блогах размахивают, уже даже вне питон-дискуссий.

Это утверждение что при многочисленных прогонах теста - нужно репортить его минимальное время исполнения, а не среднее. С обоснованием, что если мы меряем минимальное время, то измеряется без учета побочных процессов в компьютере. И забывается, что эти побочные эффекты (лок/flush/gc.collect какой-нибудь) могут быть порождены самим теcтируемым объектом.

Нахрена мне минимальное время исполнения, если код таков что gc/page fault/прерывание драйвера/переключение потока/лок мьютекса/... срабатывает на каждом десятом присваивании? Нахрена мне минимальное значение семпла (лог)нормального распределения? Нахрена в игре показывать FPS самого быстрого кадра? Я понимаю что нужно учитывать warmup всякий кешей и выключать FireFox/скайп, но не таким же зверским образом. А если игрулька должна работать вместе с FireFox с форумом-чатом игры, то и FireFox со скайпом лучше не выбрасывать из измерений.

Вообще часто интересно смотреть на распределение времени целиком. Часто оно не "колоколообразное"-гауссианное. Если оно "колоколообразное", то интересно смотреть mean+stdev, но никак не минимальное из выборки. Для произвольных распределений можно репортить 50% - 90% - 99% - 99.9% квантили ("типа 99% клиентов получают ответ на запрос за 0.5 секунд и меньше).


  • 1
иногда пригождается и только минимальное время - если мерять маленький kernel (до сотен инструкций) при помощи rdtsc

Edited at 2012-03-09 07:22 pm (UTC)

Ну да, если мы точно знаем из каких независимых компонентов состоит результат - то можно их по одному оптимизировать.

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

  • 1