Комментарии 9
Статья конечно полезная, но что-то мне подсказывает что 9 случаев проблем с памятью из 10 в python связаны с pandas :)
9 из 10 проблем с памятью в питоне связаны с тем, что в питоне обертки над обертками - в лучшем случае
9 из 10 оберток между тем над C* либами или компонентами с их использованием, тогда признаем его виноватым?
Нет не признаем. С хорошо обращается с памятью в отличие от питона. В котором не только сборщик мусора, так ещё и простые типы жрут как не в себя.
С вообще никак не обращается с памятью, программист отвечает за работу с её выделением/освобождением вручную. В пайтон же есть сборщик мусора и ещё огромное количество сахара, который упрощает работу программисту и при этом увеличивает производительность кода. Вот вроде бы от GIL пытаются отказаться. А с того что GC жрет как не в себя я усмехнулся) простые типы (int, str, list, ...) реализованы на С, и по большей части работают as is, так что жрут не сильно больше чем ожидается. В общем я тут в процессе написания своего языка, который по сложности обещает быть +- как питон, но при этом компилируемый. короче скоро статья будет, и я там буду рассматривать всевозможные трюки для оптимизации итогового кода, и вы не поверите, сколько методов взято из python!
Интересно, что же вы такое делаете, что вам надо добавлять в файл такие гигантские списки, которые вызывают Аут оф мемори ??
Как правильно заметил коллега выше- "Аут оф мемори здорового человека" в питоне - это подготовка больших массивов данных в пандасе и последующее их запихивание, например, в нейросеть.. вот на эту тему было бы интересно расширить кругозор..
Я стакливался с этой ошибкой в скрипте отправки метрик в Graphite. Когда сервис отключали для плановых работ, накапливалось столько данных, что скрипт не мог их переварить.
Отсылка к Дейлу Карнеги, уважуха
Как перестать жить и начать беспокоиться о потреблении памяти