Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)

[@alesto]

Спасибо! Статья интересная!
Интересно как дела обстоят с памятью в руби и питоне?

[@SiTLar]

О перле уже ни кто не вспоминает :-))

[@kornerz]

#!/usr/bin/perl
$startMemory = `ps h -o vsz $$`;
@array = (1 .. 100000);
print `ps h -o vsz $$` - $startMemory;

1.9 Мб на 32-битной, или 3Мб на 64-битной системе.

[@HomoErectus]

offtopic: Наблюдение из жизни на Perl пишут обычно довольно хорошие программисты. Не хочу никого задеть, но perl крут.

[@xexsus]

Читая интернеты, тоже создаётся такое впечатление, но в жизни бывает наоборот, если исходить из моего личного опыта.

[@xexsus]

Думаю, тут дело в что то рассвет Perl был раньше, и люди подсевшие на него в то время, сейчас набрались большего экспириенса, чем люди только начинающие и выбирающие популярные сегодня языки.

[@homm]

В Питоне a = range(100000) дает увеличение памяти:
4,1 мб → 7,2 мб. Того ровно 31 байт на значение.

Это 64-х битная OS X. Кстати, Пэхапэ для скрипта приведенного в самом начале выдает 21 мегабайт.

[@MaksSlesarenko]

Как отмечалось выше, PHP много места резервирует для работы сборщика мусора. В реальном примере работа с большими массивами /объектами производится в пределах метода или функции, а это значит, что при выходе из него все неиспользуемые переменные в данной области видимости удаляются, и внутренняя память PHP освобождается.

Это хорошо что питон расходует меньше памяти чем PHP для хранения массива, но ввиду того что я не знаком с работой сборщика мусора в питоне, это не дает мне права судить на сколько хорошо он работает с памятью.

[@homm]

Из вашего сообщения мы узнали что вы не знаете как работает сборщик мусора в Питоне и больше ничего. Пожалуйста, держите нас в курсе событий.

[@MaksSlesarenko]

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

[@homm]

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

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

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

[@homm]

Ну а счас то, блядь, что не так в моем комментарии? Откуда минусы, ебаный в рот?

[@AmdY]

Гы, Вы не гламурный и использовали много непонятных слов.

numpy — я так понял python расширение, в php для массивов-стеков-очередей и т.д. есть соотвественные классы в spl, которые тоже дают серьёзный выигрыш в памяти и скорости. Если кому интересно www.php.net/manual/ru/spl.datastructures.php

[@homm]

Дают серьёзный выигрыш, который все равно меньше чем использование обычных списков в Питоне. Цифры в статье и моем комментарии.

[@AmdY]

Угу, я это прекрасно понимаю, просто привёл маленький костыль для структур, существующий в php, а то многие, судя по собеседованиям, этих вещей не знают.

[@akzhan]

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).

[@donnerjack13589]

А кроме Reference counting GC другого сборщика мусора в PHP нет? Довольно странно увидеть использование такого типа GC для динамически компилируемого языка.

[@donnerjack13589]

Хотя, с другой стороны, учитывая что скрипт живет достаточно короткое время, данный тип сборки мусора может быть наиболее оптимальным.

[@CKOPOBAPKuH]

ну, он с хитрым костылём, чтобы reference cycles не приводили к утечкам памяти www.php.net/manual/en/features.gc.collecting-cycles.php

[@donnerjack13589]

Хитрость эта известная очень: en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles. Просто интересно, насколько большой overhead даст скажем Generational Mark-Copying GC на коротко-живущий процессах.

[@bolk]

Почему вы «Си» называете «С»? Как читать такого уродца?

C в отличие от PHP не управляет памятью за вас. Вы должны самостоятельно следить за распределением памяти.

[@tzlom]

а почему вы PHP называете PHP а не «пиэйчпи» или «похапе» или одно из кучи других фонетических прочтений в меру своей грамотности?

[@bolk]

Кто вам сказал, что не называю? Но мы, кажется, другое название тут обсуждаем? Ни разу на моей памяти обсуждение двух вещей одновременно не приводило к конструктиву.

«С» вполне себе реально спутать с предлогом «С». На мой взгляд, это проблема. Кроме того, я не понимаю почему не писать «Си», если язык так и называется на русском.

[@Norraxx]

У Вас я думаю достаточно хороший парсер в голове особенно когда вы на информатическом ресурсе.

[@bolk]

Обычно я распознаю всё правильно, а в этом случае запнулся. Потому что сразу непонятно что это — название языка или предлог. Вам кажется, что всё ок, потому что вы редко читаете вслух. Вы попробуйте.

[@imalcolm]

разве в английском есть предлог «C», в статье написана именно C (англ.) а не С (рус.)

[@bolk]

Вы меня извините, но я на глаз не умею отличать англ. «С» от рус. «С».

[@imalcolm]

плохо

[@sectus]

> P.S. Все замечания по поводу перевода прошу писать в ЛС, а я постараюсь оперативно их исправить.

[@Coffin]

Если косяк с кодировками, то вполне себе можно отличить :)

[@int_index]

Как вариант — пользовательский шрифт с различным начертанием для латиницы и кириллицы.

[@pavelpromin]

— У тебя ушей робота нет

[@zim32]

14 метров… многовато конечно. Буду чаще делать unset теперь

[@lukashes]

Про сборщик мусора не забывайте, а то будете под конец работы метода unsetы ставить.

[@g00d]

а что нужно помнить про GC что б под конец работы метода ансеты не ставит ь?

[@xexsus]

При выходе из области видимости, локальные переменные будут освобождены автоматически.

[@ualinker]

Перевод просто отличный. Наверное, первый раз читал статью и не знал, что это перевод пока в самом низу не наткнулся на ссылку.

[@Freem]

offtop: Плохо читали, после первого абзаца примечание :)

[@ualinker]

виноват) пропустил вступление и сразу приступил к выкладкам потому что сам недавно столкнулся с подобной ситуацией в Apache AVRO

[@sectus]

Спасибо, старался.

[@inakrin]

codepad.viper-7.com лежит. Хабраэффект?

[@inakrin]

(Ссылка «Это можно сделать on-line»)

[@jrip]

В теории интересно, но на практике странно это — писать на PHP нечто обрабатывающее очень большие объемы данных, лично я ни разу не встречал массивов на 100к элементов в PHP, все решалось другими способами.

[@mc_dir]

сейчас обрабатываю массив 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)

[@Xazzzi]

Когда я увлекся покером, то пытался на РНР сделать рассчет возможных комбинаций… около 2.5M их было. Ни разу не смог дождаться завершения работы скрипта.
Потом переписал все на С (или С++, не помню уже). Программа отработала за 6 секунд, и выдала все, что я от нее хотел.
Это я к чему, может РНР — не лучший инструмент для обработки таких обьемов данных?

[@jrip]

Тут смотря какая задача. Если просто обработать несложным алгоритмом даже большой массив 1 — 2 раза, то все ок. А вот если алгоритм сложный то это будет либо долго либо никто не даст гарантий что оно до конца выполнится. Все таки php по-моему предназначен для выполнения чего-нибудь за некоторое конечное количество времени, в идеале до 30 секунд. Да конечно и демонов можно на нем писать, я даже как-то пробовал… но стабильность и скорость очень сильно хромает.

[@kamiram]

а в Python, разве range — массив создает а не итератор?

[@Norraxx]

docs.python.org/library/functions.html#range
function to create lists containing arithmetic progressions

[@deus]

xrange итератор

[@homm]

В версии 2 отдает список, начиная с третьей — итератор.

[@unity_ultra_hardcore]

>> супер-динамического языка PHP
оххх

[@Sanovskiy]

У меня в x64 бунте вообще 24 метра вышло. :(
Пора валить в питонисты.

[@milast]

… всегда голодный этот php, бесконечные циклы долго выполняет… да-да, а еще php не может пылесосить, и мыть посуду.
Просто его нужно использовать по назначению, как я считаю, и с умом.

[@DjOnline]

В ситуациях, когда нужна скорость, можно ли каким-то образом сохранить образ массива (без сериализации, без igbinary) и затем просто восстановить его в памяти, не пересоздавая его заново?
В C — да, memcpy и вперёд, хоть по сети передавай, хоть в кэш ложи. В PHP так невозможно?

[@sectus]

Невозможно.

[@olezh]

void *pData; // Данные

void *pDataPtr; // ??? Что это ???

Что это? pData pointer же. Указатель на pData