Управление памятью в Python
HTML-код
- Опубликовано: 19 июн 2024
- В этом видео я постараюсь максимально просто объяснить, как работает управление памятью (memory management) в Python. Ну и конечно без схем не обошлось)
Канал в тг - t.me/PythonClinicChnl
Таймкоды:
00:00 - интро
00:55 - стэк и куча
08:16 - арены
10:42 - пулы
11:26 - блоки
18:04 - выводы
19:59 - аутро
Вот контента такой глубины в русскоязычном Ютубе очень не хватает. Спасибо ❤
всё будет)
Супер! Огромное спасибо!
Формат бомба.) Информация заходит чётко.
Теперь есть более глубокое представление об автоматизации работы с памятью в python.
Жду видео о ссылках и объектах!)
и оно таки будет на следующей неделе) спасибо)
Блин у меня "куча" ассоциируется с гером фильма ;)
А вообще видео очень хорошее, стало намного понятней как работает память в python, хоть я и новичок в программировании.
Спасибо!
3 раза поспал, спасибо)
19:23 Это наверное самое смешное что я слышал за последние годы про утечку. Мало кто поймет..
Супер! Спасибо за качественны и понятный материал!
Годный видос, не смотря на то что особо никогда не заморачивался с памятью в python из-за встроенного инструментария по её организации, всё равно интеересно послушать как это всё работает под капотом. Много нового для себя узнал). Интересно было бы посмотреть видео похожего формата где бы на низком уровне объяснялись генераторы)
молодец, хорошее объяснение такой сложной темы👍
Крутое объяснение материала! Спасибо!
Отличное видео, посмотрел с удовольствием
супер просто и понятно. Ставлю лайк)
Спасибо за объяснение, вполне доходчиво
randomly found your channel, very useful
thanks!
От babushki спасибо:)))
Спасибо, коллега! Хотелось задать несколько вопроса:
1. Указатель freeblock есть , а указатель untoched нет? Почему вообще их учитывают раздельно?
2. Как думаешь, почему partially full арену/пул нельзя отдать OS? Ведь память на современных системах - виртуальная, и можно просто размаппить неиспользованный кусок(предположение - маппится contiguous region , и если отмаппить его кусочек, туда всё равно ничего не влезет, те фрагментация на уровне физической памяти )
3. Есть ли какие-то предпочтения по группировке? Например, хранить элементы массива рядом с самим массивом (который, как известно, хранит только ссылки на содержимое)
Спасибо за интересную тему!
1. есть и untouched, но он не настолько интересен, freeblock позволяет переиспользовать "арендованную" память, это чаще всего важнее, чем использовать новую, и поэтому их учитывают отдельно, экономия на всём и всегда
2. соглашусь, что в теории такая операция возможна, но на практике она была бы досточно "дорогой" для самой os + не совсем понятно, в какой именно момент отдавать кусок неиспользованной арены обратно, нужно быть прям уверенным, что оно больше не понадобится, а это возможно только если программа завершена, но в этом случае всё отдадим и так
3. нет, по умолчанию нет, потому что предпологается, что обращение по ссылке происходит за постоянное время, но в некоторых ситуациях своего рода группировка реализуется специально, например для массивов numpy, а в некоторых она возникает сама (если объекты улетают в один пул)
@@pythonclinic спасибо за ответ! Насчёт константного доступа: в случае кэширования есть разница)
Привет, классный контент,но мне все еще не дают покоя эти вопросы
1)Почему в python мы не храним объекты с неизменяемым типом данных в stack,как в си ,ведь мы знаем их размер?
2)В 1 блоке может быть только 1 объект?
3)Как интерпретатор понимает какой размер объекта,есть ли для базовых неизменяемых,для изменяемых типов заданные значения(int=8б)? если изменяемый тип становиться больше блока ,я так понимаю он выносит его в блок с большем размером
ох, интересные вопросы, попробую аккуратно ответить:
1) свечку не держал, но предположу, что такая архитектура придумана для гибкости работы со всеми объектами по ссылке, грубо говоря ко всем объектам применяются одинаковые стандарты подсчёта ссылок и отправления их в последний путь
2) в теории да, если он прям огромный
3) заданных значений нет, объекты в теории прям бесконечно большие, но есть такой момент, что изменяемые объекты меняться не могут, поэтому мы их размер один раз при создании вычисляем и на этом успокаиваемся, а изменяемые объекты это всегда наборы ссылок, которые в свою очередь могут ссылаться либо на неизменяемые (размер которых мы знаем), либо на изменяемые, которые тоже суть наборы ссылок и так до конца, пока по всем ссылкам мы не упрёмся либо в неизменяемые, либо в пустые объекты, и тогда для изменяемых объектов достаточно просто пройти по всем ссылкам и посчитать размер всего, что мы встретим на своём пути (но интерпретатор этого не делает вообще говоря, ему не нужно, потому что важно разложить в памяти именно неизменяемые объекты, и для них знать размер, а всякие списки это всего лишь оболочки пусть и со своей логикой хранения внутри, но всё равно там только ссылки в основном, их размер фиксирован и относительно мал)
Очень полезная информация. Такие темы чаще всего игнорятся создателями контента по питону.
А как такую тему сделать на diagrams?
В опциях диаграмы включить Sketch
Очень интересно! Спасибо! Менеджер так работает только в CPython или в других интерпретаторах тоже?
Похожие концепции используются в большинстве языков с автоматическим управлением памятью, но они все различаются в деталях, иногда очень сильно, например, в C# тоже есть стэк и куча, но в обоих будут храниться прям живые объекты, а переменные будут существовать вообще отдельно
Отличный ролик, здорово, что делаешь не очередной курс по основам python, а копаешь глубже. Но после просмотра появилась пара вопросов которые не раскрыты в видео:
1. Как определяется велечина блока в пуле? Насколько я знаю она определяется при первом заполнении свободного пула велечиной равной или большей велечине объекта который мы хотим положить в пул, а далее весь пул заполняется блоками равного размера. Но могу ошибаться.
2. Что происходит если велечина объекта превышает велечину пула? Что происходит если велечина объекта превышает велечину арены?
Спасибо за отличные вопросы, разбираемся:
1. Идея верная, размер блоков в пуле подстраивается под первый добавленный объект, но при этом размеры блоков заранее предопределены - 8, 16, 24, 32, 40, ... , 512 байт. Из этих размеров выбирается минимальный, в который влезет новый объект.
2. В таких случаях будет работать совершенно другой механизм выделения памяти, если объект не влезает в пул, и его нельзя разбить на части и как-то эти части связать, то pvm попытается спихнуть ответственность на операционную систему, которая конечно же справится с этой задачей, если у неё самой будет достаточно памяти "на руках". Это, очевидно, очень плохой сценарий, так как этот объект выпадает из стандартного флоу управления памятью, и приводит к дополнительной фрагментации памяти на уровне операционной системы.
@@pythonclinic Спасибо за подробный ответ.
мы можем как то практически применять знание о распределении памяти ? Как то положительно влиять на это, если этот процесс автоматизирован?
процесс полностью автоматический, мы можем немного на него влиять через модуль gc (сборщик мусора), а ещё мы можем сделать некоторые выводы о работе с объектами в памяти, я расскажу об этом в дополнительных видео
Не подскажите, как сделали такую визуализацию в draw io? Не нашел в стандартных настройках =/
В настройках диаграммы нужно включить параметр sketch
Формат хороший, но экологично и экономично это все-таки разные понятия)
экологично, потому что уже выделенная память переиспользуется
А если объект 1мб он поделится на 4 арены? как произойдёт запись?
не, не поделится, большинство объектов в пайтон относятся к сложно устроенным ссылочным типам данных, части которых не будут превышать лимит и они будут хранится в разных аренах
Можно узнать откуда черпал инфу?)
никаких секретов, это документация и исходный код Python)
утекать память будет автоматически XDDD
Grazia Signore.