Мне тут долго и убедительно рассказывали, какой в питоне плохой GC, что я даже засомневался. Он что, правда не умеет освобождать однажды занятые страницы памяти? Логично, что если я напишу код, который постоянно создает объекты и уничтожает ссылки на них, то GC не будет успевать их переваривать без принудительного gc.collect() и потребление памяти будет постоянно расти. Но неужели нереально заставить интерпретатор отпустить память и отдать ее другому приложению? Или я вообще пишу бред?

Не переживайте. Все переварится, сколлектится, будет отдано другому приложению.
http://stackoverflow.com/questions/15455048/releasing-memory-in-python

Если GC не успевает очищать память, то нужно или оптимизировать приложение, чтобы оно не создавало столько мусора, или улучшать железо. Это не проблема питона, так будет в любом языке имеющем GC.

Soteric
Интересная получается картина. Выходит, что в интерпретаторе в определенной структуре данных хранятся все аллоцированные объекты, например, инты. В итоге уничтожение объекта выкидывает его из оттуда, но сам размер структуры может измениться мало, потому что память под нее уже зааллоцирована с концами. Т.е., действительно, к потреблению памяти, которое было сразу после запуска интерпретатора, вернуться невозможно.

И это нормально :)

Soteric
Ну а как же все те вещи с “непрерывным программированием”, когда свеженаписанный код просто встраивается в глобальный эвентлуп приложения без рестарта и проблем с ресурсами? :) Получается, что чем дольше работает приложение - тем неизменно больше оно будет жрать память, причем это будет зависеть от размеров объектов, с которыми оно работает, и, например, от количества пользователей, особенно когда много тредов. Как-то это печально, хоть и нормально.

P.S. и да, я понимаю, что realloc будет опускать всю производительность ниже плинтуса в таком случае, но все равно за державу обидно.

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

Soteric
гипотетическая ситуация - мы читаем построчно данные из произвольного набора. Где-то в середине данных попадается длиннющщая строка, например, гигантский json, записанный в одну строку. Все, даже если мы читали эти данные итератором - большой кусок памяти, в который была прочтена эта строка, останется неосвобожденным до конца работы приложения. Верно?

Enchantner
Все, даже если мы читали эти данные итератором - большой кусок памяти, в который была прочтена эта строка, останется неосвобожденным до конца работы приложения. Верно?

С чего бы.
Маловероятно, что GC освободит всю память сразу после чтения следующей строки - что логично, вдруг следующая строка у вас такая же длинная или вы решили seek() сделать.
Первый цикл очистки GC пройдет сразу после выходя из цикла чтения.
Если вы закрываете файл - следующий цикл очистки.
Если GC в первом цикле не очистил память, он это сделает во втором.

Но это лирика, я не уверен в правильности постановки задачи.
Понимаете, пока даже не говорим о выборе инструмента и не обсуждаем вопрос обработки очень больших данных, не помещающихся целиком в память.
А ведь могут быть и данные, которые целиком считать нельзя, т.к. объем памяти плюс дисковый своп не могут их вместить. :)

Программистские задачи возникают из определенных задач из конкретной предметной области.