Comments 17
24 закладки и 0 комментариев. Буду первым) Спасибо за интересную статью)
Спасибо, было интересно!
Хотел бы добавить комментарий - не стоит забывать, что в случае gc.set_debug(gc.DEBUG_LEAK) весь мусор уедет в gc.garbage и там и останется.
Спасибо! Полезно.
Превосходно, спасибо!
пойду в гит звезду поставлю. спасибо
В раздел с инструментами для анализа памяти очень рекомендую добавить Memray. Он гораздо нагляднее tracemalloc.
Прикольно, но не в плане критики а дискуссии ради. Вот зачем эти знания даже опытному питонисту не говоря уже о рядовом? Понятно что любопытно, понятно что лучше знать чем не знать. Но ни в одном проекте никогда вообще не видел чтобы нюансами управления памятью хоть кто то заморачивался, на собесах да, спрашивают, в работе - нет. Питон в этом плане предоставляет хорошую надежную абстракцию, не требующую от программиста каких бы то ни было усилий. Краем уха слышал что в геймдеве отрубают gc и управляют памятью в полу-ручном режиме, но в других областях прям нет.
В целом, да, для общего развития и любопытства ради. Когда вышла книга и я её прочёл, загорелся идеей сделать визуализатор, но отложил в долгий ящик, вот наконец руки дошли. Думаю в основном пригодится как раз на собеседованиях, показать общую эрудицию, ну и местами где может понадобиться производительность и где могут быть жесткие рамки по памяти, на больших объёмах данных. А так согласен с точкой зрения, сам пока не сталкивался в работе с этим, кроме циклических ссылок и работы со сборщиком мусора местами, но это было скорее исключение
Ну, это вы зря. В области обработки больших массивов данных ловить всякие аут-оф-мемори и прочее такое. Еще бы что-то подобное для гпу..
Спасибо за статью. А насколько сложно сделать реальную визуализацию?
Визуализация управления памятью в Python: что творится внутри?