много программ в одном gtk mainloop

Если одна упадет — упадут все.

и с чего это сильно будет экономить память?

Я не знаю, я замерял - чуть ли не по 5 метров экономии с каждого включения.

Может общий интерпретатор питона, сделавший import gtk в сумме 1 раз реально быстрей и легче?

А, еще - стартует оно быстрей.

ну это же питон. 5 Мб - это разве много для него?

ну это же питон. 5 Мб - это разве много для него?

5Мб - это слишком много для меня.

ну это же питон. 5 Мб - это разве много для него?

У меня не только питон, у меня еще и жаба.

Да не та, которой 256 Мб мало, а та, из-за которой у меня на основном компе 256 Мб всего, а на мелких целевых железках и того меньше.

а вы уверены, что вам нужен питон? у него с памятью не все хорошо

Да, ибо язык хороший, знакомый, много gtk, dbus и хочу без мороки юзать биндинги к любой чепухе от wnck до bluez. Пока следущий по этим критериям - Vala, а значит мне нужен питон.

питон от природы жрет много памяти (и от стиля программирования). да и процессор любит. очень

да и не стоит надеется на gc в питоне - практика показала, что он не смог очиститься от выделения 2 Гб простых классов, наследников от dict. У вас может быть тоже самое

практика показала, что он не смог очиститься от выделения 2 Гб простых классов, наследников от dict

Это зависит от рукожопия практиканта.

Чем хороша/плоха идея?

Хочу сделать также. Постоянно держать запущенными в одном интерпретаторе dmenu-подобную хрень и свой файловый менеджер, а то они вытесняются из кеша и через некоторое время очень медленно стартуют.

Руки заточаны ровно.

Читаем описание gc питона. Там сказано, что gc работает хорошо в большинстве случаев, но не гарантирует очистку всех неиспользуемых объектов

man refcounting & weakref

Питонячий gc просто как палка. Не суметь удалить объект это надо сильно постараться.

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

джава-программисты смеются над вами.

Как там пермген поживает?

отлично. Permgen error последний раз видел очень давно. К слову, даже тогда он возникал исключительно от частых передеплоев. в продакшене это быть не может. Там аппликуха загрузилась. всякие фреймворки посоздавали свои классы и все, больше в пермген ничего не идет. И он постепенно опускается до реально занятого значения.

Гугл с тобой не согласен

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

О том и речь. В продакшене зверек, как правило, подкрадывается незаметно. Уже все и позабыть успели, а тут, с очередным фиксом, хлобысь и весь контейнер надо рестартить. Энтерпрайз, хуле.

вообще говоря, конкретно эта проблема - результат кривых ручек программистов. а не jvm как таковой. Если бы все писали выгружающиеся классы, такого бы не было, но увы.

Циклические ссылки в питоне допуостимы

Циклические ссылки в питоне допуостимы

Кто мешает их разбить? Читни-ка матчасти, дружок.

Иногда мешает

Но проблема не в этом. Ключевые слова: память не возвращается системе, фрагментация кучи. Это если предположить, что gc работает идеально

Ключевые слова: память не возвращается системе, фрагментация кучи.

Это ты уже на плюсы перешел?

нет. это питон. и его внутренняя каша.

в общем течет он. как не прискорбно. Иногда правда стабилизируется

в общем течет он. как не прискорбно.

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

Хотя меня утечки не донимают. На сервере крутится in-memory очередь сообщений, написанная на tornado. Как было 8mb полгода назад, так и сейчас столько же занимает. Мой опыт говорит, что написание надежных сервисов на питоне достаточно простая задача, в отличие от.

> С этим надо просто смириться. Или валгринд в зубы и вперед.

Причина утечек памяти в питоне может быть недоработка в gc

Причина утечек памяти в питоне может быть недоработка в gc

Это примитивный подсчет ссылок. Ты или держишь ссылку на объект или не держишь. Какие недоработки? Давай примеры, уж.

Циклические ссылки. Обещали, что будут удаляться. Потом написали, что вероятно, будут удаляться. WeakLink аналогично

Это не примеры, а так, болтология.

Ладно. У нас есть код, который загружает на стеке dict'ов на 2 Гб. Потом мы просто выходим из функи. А 2 Гб остаются выделенные. ПРи следующем вхождении он откусывает еще (правда не 2 Гб, меньше)

И так легко доходит до 8 Гб

Циклические ссылки в питоне допуостимы

Ничего подобного, gc как раз и занимается тем что вычисляет замкнутые циклы.

А 2 Гб остаются выделенные

сделай gc.collect(). По-дефолту оно каждые 100(кажись) инструкций отрабатывает, поэтому иногда видно что объекты не сразу высвобождаются.

> Ничего подобного, gc как раз и занимается тем что вычисляет замкнутые циклы.

А я что сказал?

ну вы меня за детсад держите? gc.collect() делали. Даже ждали. Даже запускали вского говна типа while 1;

Спрошу прямо: можешь дать код, который течет?

нет. продакшен и NDA

что-то типа этого:

class A(dict): pass

def f(): a = [] for i in xrange(1,1000): a.append( A({1:2, 3:4, deepcopy(a)} )

NDA

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

Мы ее решили. Писать тест времени нет

1 комментарий по теме - хоть сноси.