Как стать автором
Обновить

Комментарии 57

Спасибо! Статья интересная!
Интересно как дела обстоят с памятью в руби и питоне?
О перле уже ни кто не вспоминает :-))
#!/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 мегабайт.
Как отмечалось выше, PHP много места резервирует для работы сборщика мусора. В реальном примере работа с большими массивами /объектами производится в пределах метода или функции, а это значит, что при выходе из него все неиспользуемые переменные в данной области видимости удаляются, и внутренняя память PHP освобождается.

Это хорошо что питон расходует меньше памяти чем PHP для хранения массива, но ввиду того что я не знаком с работой сборщика мусора в питоне, это не дает мне права судить на сколько хорошо он работает с памятью.
Из вашего сообщения мы узнали что вы не знаете как работает сборщик мусора в Питоне и больше ничего. Пожалуйста, держите нас в курсе событий.
Вы не могли не заметить, что мое сообщение выше является ответом на ваш пример, который с моей точки зрения немного однобокий. Очень жаль, что вместо того что бы поделится своими знаниями, которые судя по профилю у вас есть, вы решили показать свой характер.
Что-то я не заметил, что вы меня о чем-то спросили. Буду отвечать наугад.
В Питоне (речь конечно про cPython) как и в Пэхапэ есть подсчет ссылок и сборщик мусора для циклических ссылок. «Переменные при выходе их области видимости удаляются» и там и там. «Это хорошо что питон расходует меньше памяти чем PHP для хранения массива» — определенно.

Различия скаладываются во-первых оттого, что в Питоне списки это тип данных со строго определенным функционалом, а не все в кучу как Array в Пэхапэ. И нет такого понятия, как переменная-ссылка. Поэтому подсчет ссылок для значений не ведется, только для переменных.

Ну и если рассматривать способы уменьшить расход памяти, можно вспомнить массивы numpy, кторые занимают ровно столько памяти, сколько нужно их элементам. Но естественно, все элементы в таком случае будут одного типа.
Ну а счас то, блядь, что не так в моем комментарии? Откуда минусы, ебаный в рот?
Гы, Вы не гламурный и использовали много непонятных слов.

numpy — я так понял python расширение, в php для массивов-стеков-очередей и т.д. есть соотвественные классы в spl, которые тоже дают серьёзный выигрыш в памяти и скорости. Если кому интересно www.php.net/manual/ru/spl.datastructures.php
Дают серьёзный выигрыш, который все равно меньше чем использование обычных списков в Питоне. Цифры в статье и моем комментарии.
Угу, я это прекрасно понимаю, просто привёл маленький костыль для структур, существующий в 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 для динамически компилируемого языка.
Хотя, с другой стороны, учитывая что скрипт живет достаточно короткое время, данный тип сборки мусора может быть наиболее оптимальным.
Хитрость эта известная очень: en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles. Просто интересно, насколько большой overhead даст скажем Generational Mark-Copying GC на коротко-живущий процессах.
>> Хитрость эта известная очень

Йоды магистра последователь обнаружен
Почему вы «Си» называете «С»? Как читать такого уродца?
C в отличие от PHP не управляет памятью за вас. Вы должны самостоятельно следить за распределением памяти.
а почему вы PHP называете PHP а не «пиэйчпи» или «похапе» или одно из кучи других фонетических прочтений в меру своей грамотности?
Кто вам сказал, что не называю? Но мы, кажется, другое название тут обсуждаем? Ни разу на моей памяти обсуждение двух вещей одновременно не приводило к конструктиву.

«С» вполне себе реально спутать с предлогом «С». На мой взгляд, это проблема. Кроме того, я не понимаю почему не писать «Си», если язык так и называется на русском.
У Вас я думаю достаточно хороший парсер в голове особенно когда вы на информатическом ресурсе.
Обычно я распознаю всё правильно, а в этом случае запнулся. Потому что сразу непонятно что это — название языка или предлог. Вам кажется, что всё ок, потому что вы редко читаете вслух. Вы попробуйте.
разве в английском есть предлог «C», в статье написана именно C (англ.) а не С (рус.)
Вы меня извините, но я на глаз не умею отличать англ. «С» от рус. «С».
плохо
> P.S. Все замечания по поводу перевода прошу писать в ЛС, а я постараюсь оперативно их исправить.
Если косяк с кодировками, то вполне себе можно отличить :)
Как вариант — пользовательский шрифт с различным начертанием для латиницы и кириллицы.

— У тебя ушей робота нет
НЛО прилетело и опубликовало эту надпись здесь
14 метров… многовато конечно. Буду чаще делать unset теперь
Про сборщик мусора не забывайте, а то будете под конец работы метода unsetы ставить.
а что нужно помнить про GC что б под конец работы метода ансеты не ставит ь?
При выходе из области видимости, локальные переменные будут освобождены автоматически.
Перевод просто отличный. Наверное, первый раз читал статью и не знал, что это перевод пока в самом низу не наткнулся на ссылку.
offtop: Плохо читали, после первого абзаца примечание :)
виноват) пропустил вступление и сразу приступил к выкладкам потому что сам недавно столкнулся с подобной ситуацией в Apache AVRO
Спасибо, старался.
codepad.viper-7.com лежит. Хабраэффект?
(Ссылка «Это можно сделать on-line»)
В теории интересно, но на практике странно это — писать на PHP нечто обрабатывающее очень большие объемы данных, лично я ни разу не встречал массивов на 100к элементов в PHP, все решалось другими способами.
сейчас обрабатываю массив 32 000 000… и это еще маленький )))
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 секунд, и выдала все, что я от нее хотел.
Это я к чему, может РНР — не лучший инструмент для обработки таких обьемов данных?
Тут смотря какая задача. Если просто обработать несложным алгоритмом даже большой массив 1 — 2 раза, то все ок. А вот если алгоритм сложный то это будет либо долго либо никто не даст гарантий что оно до конца выполнится. Все таки php по-моему предназначен для выполнения чего-нибудь за некоторое конечное количество времени, в идеале до 30 секунд. Да конечно и демонов можно на нем писать, я даже как-то пробовал… но стабильность и скорость очень сильно хромает.
а в Python, разве range — массив создает а не итератор?
xrange итератор
В версии 2 отдает список, начиная с третьей — итератор.
У меня в x64 бунте вообще 24 метра вышло. :(
Пора валить в питонисты.
… всегда голодный этот php, бесконечные циклы долго выполняет… да-да, а еще php не может пылесосить, и мыть посуду.
Просто его нужно использовать по назначению, как я считаю, и с умом.
В ситуациях, когда нужна скорость, можно ли каким-то образом сохранить образ массива (без сериализации, без igbinary) и затем просто восстановить его в памяти, не пересоздавая его заново?
В C — да, memcpy и вперёд, хоть по сети передавай, хоть в кэш ложи. В PHP так невозможно?
Невозможно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.