Комментарии 58
Спасибо! Статья интересная!
Интересно как дела обстоят с памятью в руби и питоне?
Интересно как дела обстоят с памятью в руби и питоне?
О перле уже ни кто не вспоминает :-))
#!/usr/bin/perl
$startMemory = `ps h -o vsz $$`;
@array = (1 .. 100000);
print `ps h -o vsz $$` - $startMemory;
1.9 Мб на 32-битной, или 3Мб на 64-битной системе.
offtopic: Наблюдение из жизни на Perl пишут обычно довольно хорошие программисты. Не хочу никого задеть, но perl крут.
Читая интернеты, тоже создаётся такое впечатление, но в жизни бывает наоборот, если исходить из моего личного опыта.
Думаю, тут дело в что то рассвет Perl был раньше, и люди подсевшие на него в то время, сейчас набрались большего экспириенса, чем люди только начинающие и выбирающие популярные сегодня языки.
В Питоне a = range(100000) дает увеличение памяти:
4,1 мб → 7,2 мб. Того ровно 31 байт на значение.
Это 64-х битная OS X. Кстати, Пэхапэ для скрипта приведенного в самом начале выдает 21 мегабайт.
4,1 мб → 7,2 мб. Того ровно 31 байт на значение.
Это 64-х битная OS X. Кстати, Пэхапэ для скрипта приведенного в самом начале выдает 21 мегабайт.
Как отмечалось выше, PHP много места резервирует для работы сборщика мусора. В реальном примере работа с большими массивами /объектами производится в пределах метода или функции, а это значит, что при выходе из него все неиспользуемые переменные в данной области видимости удаляются, и внутренняя память PHP освобождается.
Это хорошо что питон расходует меньше памяти чем PHP для хранения массива, но ввиду того что я не знаком с работой сборщика мусора в питоне, это не дает мне права судить на сколько хорошо он работает с памятью.
Это хорошо что питон расходует меньше памяти чем PHP для хранения массива, но ввиду того что я не знаком с работой сборщика мусора в питоне, это не дает мне права судить на сколько хорошо он работает с памятью.
Из вашего сообщения мы узнали что вы не знаете как работает сборщик мусора в Питоне и больше ничего. Пожалуйста, держите нас в курсе событий.
Вы не могли не заметить, что мое сообщение выше является ответом на ваш пример, который с моей точки зрения немного однобокий. Очень жаль, что вместо того что бы поделится своими знаниями, которые судя по профилю у вас есть, вы решили показать свой характер.
Что-то я не заметил, что вы меня о чем-то спросили. Буду отвечать наугад.
В Питоне (речь конечно про cPython) как и в Пэхапэ есть подсчет ссылок и сборщик мусора для циклических ссылок. «Переменные при выходе их области видимости удаляются» и там и там. «Это хорошо что питон расходует меньше памяти чем PHP для хранения массива» — определенно.
Различия скаладываются во-первых оттого, что в Питоне списки это тип данных со строго определенным функционалом, а не все в кучу как Array в Пэхапэ. И нет такого понятия, как переменная-ссылка. Поэтому подсчет ссылок для значений не ведется, только для переменных.
Ну и если рассматривать способы уменьшить расход памяти, можно вспомнить массивы numpy, кторые занимают ровно столько памяти, сколько нужно их элементам. Но естественно, все элементы в таком случае будут одного типа.
В Питоне (речь конечно про cPython) как и в Пэхапэ есть подсчет ссылок и сборщик мусора для циклических ссылок. «Переменные при выходе их области видимости удаляются» и там и там. «Это хорошо что питон расходует меньше памяти чем PHP для хранения массива» — определенно.
Различия скаладываются во-первых оттого, что в Питоне списки это тип данных со строго определенным функционалом, а не все в кучу как Array в Пэхапэ. И нет такого понятия, как переменная-ссылка. Поэтому подсчет ссылок для значений не ведется, только для переменных.
Ну и если рассматривать способы уменьшить расход памяти, можно вспомнить массивы numpy, кторые занимают ровно столько памяти, сколько нужно их элементам. Но естественно, все элементы в таком случае будут одного типа.
Ну а счас то, блядь, что не так в моем комментарии? Откуда минусы, ебаный в рот?
Гы, Вы не гламурный и использовали много непонятных слов.
numpy — я так понял python расширение, в php для массивов-стеков-очередей и т.д. есть соотвественные классы в spl, которые тоже дают серьёзный выигрыш в памяти и скорости. Если кому интересно www.php.net/manual/ru/spl.datastructures.php
numpy — я так понял python расширение, в php для массивов-стеков-очередей и т.д. есть соотвественные классы в spl, которые тоже дают серьёзный выигрыш в памяти и скорости. Если кому интересно www.php.net/manual/ru/spl.datastructures.php
memoryBefore = `ps h -o vsz #{Process.pid}`.to_i
v = (1..100000).to_a
memoryAfter = `ps h -o vsz #{Process.pid}`.to_i
puts "Mem: #{memoryAfter - memoryBefore}"
560Kb (32bit Debian Squeeze, ruby 1.9.3-p125).
А кроме Reference counting GC другого сборщика мусора в PHP нет? Довольно странно увидеть использование такого типа GC для динамически компилируемого языка.
Хотя, с другой стороны, учитывая что скрипт живет достаточно короткое время, данный тип сборки мусора может быть наиболее оптимальным.
ну, он с хитрым костылём, чтобы reference cycles не приводили к утечкам памяти www.php.net/manual/en/features.gc.collecting-cycles.php
Хитрость эта известная очень: en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles. Просто интересно, насколько большой overhead даст скажем Generational Mark-Copying GC на коротко-живущий процессах.
Почему вы «Си» называете «С»? Как читать такого уродца?
C в отличие от PHP не управляет памятью за вас. Вы должны самостоятельно следить за распределением памяти.
а почему вы PHP называете PHP а не «пиэйчпи» или «похапе» или одно из кучи других фонетических прочтений в меру своей грамотности?
Кто вам сказал, что не называю? Но мы, кажется, другое название тут обсуждаем? Ни разу на моей памяти обсуждение двух вещей одновременно не приводило к конструктиву.
«С» вполне себе реально спутать с предлогом «С». На мой взгляд, это проблема. Кроме того, я не понимаю почему не писать «Си», если язык так и называется на русском.
«С» вполне себе реально спутать с предлогом «С». На мой взгляд, это проблема. Кроме того, я не понимаю почему не писать «Си», если язык так и называется на русском.
У Вас я думаю достаточно хороший парсер в голове особенно когда вы на информатическом ресурсе.
Обычно я распознаю всё правильно, а в этом случае запнулся. Потому что сразу непонятно что это — название языка или предлог. Вам кажется, что всё ок, потому что вы редко читаете вслух. Вы попробуйте.
14 метров… многовато конечно. Буду чаще делать unset теперь
Перевод просто отличный. Наверное, первый раз читал статью и не знал, что это перевод пока в самом низу не наткнулся на ссылку.
codepad.viper-7.com лежит. Хабраэффект?
В теории интересно, но на практике странно это — писать на PHP нечто обрабатывающее очень большие объемы данных, лично я ни разу не встречал массивов на 100к элементов в PHP, все решалось другими способами.
сейчас обрабатываю массив 32 000 000… и это еще маленький )))
php тест из статьи — 21050840 байт
на питоне
все тестировалось на Linux dn 2.6.32-5-amd64 (debian)
php тест из статьи — 21050840 байт
на питоне
os.system('ps h -o vsz PID')
a = range(1,100000)
3140Kвсе тестировалось на Linux dn 2.6.32-5-amd64 (debian)
Когда я увлекся покером, то пытался на РНР сделать рассчет возможных комбинаций… около 2.5M их было. Ни разу не смог дождаться завершения работы скрипта.
Потом переписал все на С (или С++, не помню уже). Программа отработала за 6 секунд, и выдала все, что я от нее хотел.
Это я к чему, может РНР — не лучший инструмент для обработки таких обьемов данных?
Потом переписал все на С (или С++, не помню уже). Программа отработала за 6 секунд, и выдала все, что я от нее хотел.
Это я к чему, может РНР — не лучший инструмент для обработки таких обьемов данных?
Тут смотря какая задача. Если просто обработать несложным алгоритмом даже большой массив 1 — 2 раза, то все ок. А вот если алгоритм сложный то это будет либо долго либо никто не даст гарантий что оно до конца выполнится. Все таки php по-моему предназначен для выполнения чего-нибудь за некоторое конечное количество времени, в идеале до 30 секунд. Да конечно и демонов можно на нем писать, я даже как-то пробовал… но стабильность и скорость очень сильно хромает.
а в Python, разве range — массив создает а не итератор?
docs.python.org/library/functions.html#range
function to create lists containing arithmetic progressions
function to create lists containing arithmetic progressions
xrange итератор
В версии 2 отдает список, начиная с третьей — итератор.
>> супер-динамического языка PHP
оххх
оххх
У меня в x64 бунте вообще 24 метра вышло. :(
Пора валить в питонисты.
Пора валить в питонисты.
… всегда голодный этот php, бесконечные циклы долго выполняет… да-да, а еще php не может пылесосить, и мыть посуду.
Просто его нужно использовать по назначению, как я считаю, и с умом.
Просто его нужно использовать по назначению, как я считаю, и с умом.
В ситуациях, когда нужна скорость, можно ли каким-то образом сохранить образ массива (без сериализации, без igbinary) и затем просто восстановить его в памяти, не пересоздавая его заново?
В C — да, memcpy и вперёд, хоть по сети передавай, хоть в кэш ложи. В PHP так невозможно?
В C — да, memcpy и вперёд, хоть по сети передавай, хоть в кэш ложи. В PHP так невозможно?
void *pData; // Данные
void *pDataPtr; // ??? Что это ???
Что это? pData pointer же. Указатель на pData
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)