Python-сообщество

Зря я, наверное, в новичковый раздел запостил, ну да ладно.

Собственно, сабж: http://bugs.python.org/issue1123430

И статейка в тему: http://evanjones.ca/memoryallocator/python-memory.pdf

Хотелось бы выяснить ситуацию с этим делом. Ссылки по теме приветствуются.

//Кастую Андрея Светлова в тред

Отредактировано (Май 28, 2010 11:16:16)

А что тут сказать? Если собственно по вопросу - то да, неиспользуемые арены освобождаются.
Смотрите http://svn.python.org/view/python/branches/py3k/Objects/obmalloc.c?view=markup
PyObject_Free умеет это делать.

Более развернутая картина немного сложнее. В начале файла приведена схемка.

* переопределенные аллокаторы для специфических типов. Их довольно много - списки, строки, числа, instancemethod - почти любой базовый тип.
* garbage collector (у него есть свои “арены” для трех поколения объектов). Работа с памятью базируется на следующем уровне
* PyObject_* - это наш файл. Арены как большие блоки для памяти, выделяемые за раз.
* PyMem_* - тонкая надстройка над malloc/free. Почти ничего не делает, и полезна главным образом в debug mode. На самом деле современные C Runtime тоже поддерживают схему, похожую на арены - но для Питона они не столь эффективны как “доморощенная” реализация.

За последние пару лет больших багов касательно “менеджера памяти вообще” не припомню. Не факт что их на самом деле нет - но поскольку об этом не говорят - то, наверное, все хорошо. Всплывало несколько проблем для специфичных аллокаторов или деталей реализации того или иного класса/модуля. Вроде бы что-то в регулярках находили, для крайних случаев. Найдут - чинят.

Собственно в вашей статье Evan Jones и пишет, что все довольно хорошо было уже на 2005 год.
Числа все еще используют PyMem_* напрямую, в то время как, например, методы и свойства идут через garbage collector - и там свои тараканы

Большой реорганизации не было, да и трудно ее делать. Нужно иметь множество benchmarks для того, чтобы двигаться вперед. Вместе с тем нелья допустить деградации производительности.

Тем более что память - не самое узкое место. Выделяется и освобождается без “заеданий” - вот и славно.

Помнится, один из разработчиков три полных месяца упорно работал над оптимизацией главного цикла интерпретатора. Наделал кучу измерялок и вообще провел громадную работу. В результате добавил/поменял пять строк. Выиграл полтора процента - но убедился, что все уже весьма хорошо при использовании текущего подхода. Так чаще всего и бывает - работы на рубль, а эффекта на копейку. Причем каждая оптитизация ухудшает понимание общей картинки.


Куда важнее ускорение работы в других местах, с использованием принципиально новых подходов - и Unladen Swallow выглядит интересной разработкой. Когда его доведут до более или менее приличного состояния и добавят в Python 3 - увидим много открытий чудных. И опять настанет время для микрооптимизаций.

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

Классический пример - dict. Оптимизирован на использование для пространств имен.
http://svn.python.org/view/python/branches/py3k/Objects/dictnotes.txt?view=markup

Не оптимален (но и не очень плох) для словарей из тысяч элементов.
И такое - везде.

Спасибо за развёрнутый ответ. Честно говоря, я в управлении памятью не разбираюсь, но общая картина, кажется, ясна.