серпентологам

кстати, спасибо! интересно было почитать )))

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

>В первом комментарии мне сказали, что овобождение памяти зависит от системы (то есть от реализации функций malloc() free()).

Есть же такие упёртые... Неужто он думает, что разработчики питона стали бы ему врать?

Автор этой "статьи" просто ни в чём не захотел разобраться. (Наверное, именно таких на лоре называют жабобыдлокодерами?)

> Кто в курсе, чем всё кончилось?

это старая тема, в 2.5 исправить обещали

первоисточник здесь: http://evanjones.ca/python-memory.html

> это же просто - открыть сырцы - глянуть код и допистаь, что надо.

нифига это не просто. и del для массива тут ни при чём

mr, я понимаю, что ты пропагандируешь свой OpenBSD malloc, но почему
 в более других программах нет утечек/фрагментации памяти?

Вот пример аналогичный тому, что делал товарищ в питоне, но
 проделанный с помощью R (на linux, разумеется):

> seq(1,3000000,0.23)->l
> gc()
           used  (Mb) gc trigger  (Mb) max used  (Mb)
Ncells   178056   4.8     407500  10.9   350000   9.4
Vcells 13115904 100.1   33039184 252.1 37464254 285.9
> l<-NULL
> gc()
         used (Mb) gc trigger  (Mb) max used  (Mb)
Ncells 178056  4.8     407500  10.9   350000   9.4
Vcells  72431  0.6   26431347 201.7 37464254 285.9
> 
(смотрим на третью колонку (Mb) и строку Vcells)

Тут все честно - распределение 3М значений типа double(=32b) 
отъедает 100Mb памяти, которая возвращается после обнуления 
и garbage collection (gc()). ps aux все это подтверждает. 

Может всё же на free/malloc виноват, а ручки разработчиков (питона)?

> Может всё же на free/malloc виноват, а ручки разработчиков (питона)?

это не ручки, это осознанное решение -- не возвращать память выделяемую под мелкие объекты

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&...

It's a tradeoff: it's much easier to avoid in real life than it is to change the implementation in a way that would actually help (the int freelist is an important speed optimization for most integer-heavy apps).

> Тут все честно - распределение 3М значений типа double(=32b) отъедает 100Mb памяти, которая возвращается после обнуления и garbage collection (gc()). ps aux все это подтверждает.

всё дело в том что R не хранит 3M даблов как отдельные объекты.
если хочешь честно сравнить с питоном, надо брать такой вот код:

>>> import numarray
>>> x = numarray.arange(0,20000000)
>>> del x

здесь память отъедается и возвращается обратно после del.

(а сколько времени уйдёт на 3М вызовов malloc/free по 4-16 байт в win95?)

Вот тоже самое, что и раньше, но более мелко нарезанное:
> z<-list()
> for (i in 1:10000){ z[[i]]<-seq(1,300,0.23)}
> gc()
           used (Mb) gc trigger  (Mb) max used  (Mb)
Ncells   188786  5.1     407500  10.9   407500  10.9
Vcells 13088373 99.9   13405401 102.3 13870415 105.9
> for (i in 1:100){ z[[i]]<-NULL}
> gc()
           used (Mb) gc trigger  (Mb) max used  (Mb)
Ncells   188685  5.1     407500  10.9   407500  10.9
Vcells 12956922 98.9   13706526 104.6 13870415 105.9
> for (i in 201:300){ z[[i]]<-NULL}
> gc()
           used (Mb) gc trigger  (Mb) max used  (Mb)
Ncells   188585  5.1     407500  10.9   407500  10.9
Vcells 12826772 97.9   13806901 105.4 13870415 105.9
> 

Опять вся свободная память возвращается.

> Опять вся свободная память возвращается.

я не сомневаюсь что возвращается.
в питоне кусками по 300 байт тоже возвращается:

>>> l = [ ' '*300 for i in range(100000) ]
>>> del l[:]

а вот по 200 -- уже нет.

>mr, я понимаю, что ты пропагандируешь свой OpenBSD malloc, но почему в более других программах нет утечек/фрагментации памяти?

Да я ничего не утверждаю, возможно, malloc тут вообще не при чём. Тем более, что с python я вообще не знаком. Просто неправильно, когда люди делают такие утверждения, как автор "статьи". Чувствуется привкус воинствующей неграмотности...

> mr, я понимаю, что ты пропагандируешь свой OpenBSD malloc, но почему в более других программах нет утечек/фрагментации памяти?

integer freelist -- это не утечка памяти

работает пример

>>> a = range(1,10000000)
>>> del a

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28938 ugoday    16   0  119m  21m 3272 S  0.0 35.8   0:07.27 python

>>>integer freelist -- это не утечка памяти

Объясни это mr, а то он уже glibc патчить собирается.

> Объясни это mr, а то он уже glibc патчить собирается.

mr не заявляет об утечках памяти в питоне и подозрениях в криворукости разработчиков

А я где-то заявлял о "криворукости разработчиков"? Это для меня новость.

> А я где-то заявлял о "криворукости разработчиков"? Это для меня новость.

geekkoo * (*) (26.06.2006 2:25:24)
> Может всё же на free/malloc виноват, а ручки разработчиков (питона)?

>Скажите мне, Вы знаете язык программирования, в котором нельзя освободить память, нельзя даже если ты хочешь?

Жаба? Она сама хочет освобождать когда ей вздумается :)

Там можно вызвать gc, если очень постараться.

посмотрел бету 2.5 -- вроде там память возвращается, но как-то странно

похоже что она зажимает 32/64/96 мб если было однажды выделено сильно больше памяти под int'ы

Я ж не виноват, что у онанимусов упоминание ручек разработчиков питона ассоциируется только с их кривизной ;)

На самом деле подразумевалось, что такое поведение получается не автоматически, за счёт якобы кривого malloc в glibc, а встроено "вручную" разработчиками питона в их garbage collector.

Из чего можно было сделать далеко идущие выводы относительно gc в firefox...

Я вчера поигрался со строками типа >>> l = [ ' '*300 for i in range(100000) ] >>> del l[:] , зависимость освобождения памяти от аллокатора была, правда только для некоторых размеров.

Но дело не в этом. Разработчики не от балды устанавливают поведение python. Просто для большинства задач, для которых используется питон, оно быстрее. Если "автору" нужно нечто другое, то пусть извращается, придумывает что-нибудь для выхода из ситуации, а не сравнивает с другими языками, в которых якобы всё замечательно, и не кричит по сто раз, что разработчики губят питона.

>Из чего можно было сделать далеко идущие выводы относительно gc в firefox...

Не понял, а это откуда вывод? Да и нет в firefox gc, вообще-то :)