TFW объясняешь жабу погромисту на жабе, сам будучи питоновыблядком
Отличное видео, для тех кто в теме.
http://www.youtube.com/watch?v=KqUV3UUX2uQ
Помните недавнее нытье лексика о том, что рутноп съедает всю память и убивает железку? Так вот, я в это говно тоже сел.
Первой мыслью было, что бидон настолько замечательно аллоцирует объекты, что заставляет glibc'овский malloc фрагментировать память.
Я экспериментировал с openbsd'шным malloc, tcmalloc, но память не возвращалась.
Оказывается, в бидоне есть встроенный аллокатор, надстроенный над системным malloc, добавляющий еще один уровень умничанья и пулов "свободной" памяти.
Я собрал бидон --without-pymalloc и запустил с LD_PRELOAD=/usr/lib/libtcmalloc.so
Память не возвращалась.
Я сходил почитал комиксы в инторнете, потупил в чятики, глянул в процесслист и обнаружил, что RSS упало.
Предположение: Python таки освободил память, но tcmalloc решил, что память можно придержать на случай, если она еще понадобится.
Чтобы проверить это предположение, я написал биндинги к tcmalloc.
Создаем крупный объект из кучи мелких говен. generic.current_allocated_bytes растет
Удаляем его. generic.current_allocated_bytes падает, tcmalloc.pageheap_free_bytes растет
Делаем pytcm.release_free_memory(), tcmalloc.pageheap_free_bytes падает, tcmalloc.pageheap_unmapped_bytes растет, RSS падает, VSZ остается высоким.
Память действительно освободилась питоном, а tcmalloc сделал madvise(...,MADV_DONTNEED) на страницы из своего page heap.
Мораль: PYMALLOC говно. Если ты эмбеддор, это первое, что тебе нужно выдрать из питона.
Лол, а ведь в вашем петухоне действительно нет sscanf.
Вот это отсос. И не надо кукарекать про сплит регекспами.
Значит ECMAScript язык кривой, а Питон-нет?
http://habrahabr.ru/post/192098/
Ну ну.
Готовые решения на пайтоне http://code.activestate.com/recipes/langs/python/
Самый тупой способ генерировать случайные числа от нуля до нужной верхней границы (не включая), если у тебя есть [псевдо]случайные (устраивающего тебя качества) биты — взять остаток от деления на верхнюю границу. Проблема в том, что это не даст равномерного распределения. Так, например, если брать по 3 бита (минимально необходимое число), а нужно сгенерировать число в [0, 5), то очевидно результат будет вдвое чаще попадать в [0, 3), чем в [3, 5). Так что этот способ настолько тупой, что даже неправильный =).
Следующий — брать по 3 бита, пока не попадёт в нужный диапазон. Очень честный способ. Обеспечивает равномерность. Но выкидывает достаточно дорогие [псевдо]случайные биты. В принципе вероятность с первого раза попасть, куда надо, может быть около ½. Поэтому способ тоже тупой. Так, кстати, делает Питон (вот почему тут такой тег), можете посмотреть: http://hg.python.org/cpython/file/3.3/Lib/random.py функция _randbelow
Ок, хорошо, а кто скажет, как это делать нормально, чтобы распределение было равномерным, но чтобы при этом не выкидывать случайные биты?
А почему в bnw используется первотег? Прочитал тутор от Orielly "mongodb and python", красоты не понял. Да, вместо таблиц документы, и коллекции могут иметь документы разной схемы, запросы аля недосикуэль с ужасным синтаксисом через те же дикты. В чем, собственно, профит?