March 9th, 2012

nyaload

mmap/fread

Проверил скорость (код по ссылке) работы mmap/fread на FreeBSD 8.2+zfs/Ubuntu 8.04+simfs

Пятигигабайтный файл на FreeBSD считался за 8 / 6.5 секунд при помощи mmap и fread (fread быстрее!!! вроде бы это бага zfs)

На Ubuntu - за 1.1 / 3.5 секунды (mmap ожидаемо быстрей).

Разница есть, но ИМХО польза от непортируемого mmap при чтении будет заметна в редких программах. Типа загружаем 40 гигабайт, используем 1% из них, и тут же выходим, например багфиксинг алгоритма поиска в B-дереве, с постоянным перезапуском. При записи - не знаю, может удобней-быстрей патчить файлик в памяти.

Файл читался из файлового кеша (проверить без кеша не вышло - или рута нет, или /proc/sys/vm/drop_caches - permission denied в OpenVZ), но подозреваю что без кеша разницы не будет.

Под виндой проверить сложнее. На маленьких файлах не интересно и всё мгновенно, а для больших сходу лень писать 64-битный код для ftell/fread, и лень было узнавать грабли компиляции под 64-битный режим.
Проверил (код по ссылке) на гигабайтном файле, Windows7/Visual Studio 2008:
CreateFileMapping - 0.3 секунды, fread - 3.5 секунд.
nyaload

python profiling people

Кое-что меня шокирует в форумных 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 секунд и меньше).