Есть ли разница между памятью в PHP и C#?

Question

[elmoreden]

Когда изучал C# там было отдельно уделено время стеку, куче, как они работают. Сейчас иду на джуна PHP устраиваться и вот интересно: в PHP тоже логика работы памяти такая же? То есть переменные помещаются в стек, классы в кучу и т.д. или там как-то по-другому?

Comments

[Алексей Скляров]

Чтобы быть джуном в php необходимо быть сеньором в поиске ответов на свои вопросы, можете начать с: https://habr.com/ru/post/134784/

Я не думаю, что кто-то будет тратить свое время на разжевывание этой темы, пользуйтесь поиском, решение большинства проблем можно решить через поисковик

[Ипатьев]

Алексей Скляров, я думаю, больше половины информации в этой статье устарело

Answer 1

[Ипатьев]

РНР работает как консольная утилита. Запустился, поработал долю секунды, завершился.
Поэтому вопросы управления памятью в 99% случаев РНР разработчиков не волнуют. Как и её очистка
Чисто технически подробности управления памятью также полностью скрыты от разработчика.
Всё что надо знать о работе РНР с памятью - "РНР работает с памятью за тебя"
Так что в целом, единственное что вас должно интересовать - это не работать с большими объёмами данных в скрипте. Но это и так очевидная рекомендация.

Если хочется прям вдаваться в детали (хотя совершенно непонятно, зачем это джуну), то PHP insernals Memory management

Comments

[elmoreden]

То есть, куда, например, помещается значение переменной $a неизвестно?

[Ипатьев]

Не неизвестно, а непринципиально.

[AgentSmith72]

elmoreden, Адреса памяти бесполезны в PHP-скриптах, поскольку интерпретатор обрабатывает всю внутреннюю переменную.

[alexalexes]

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

[Adamos]

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

[Vitsliputsli]

Adamos, если речь про fixed array, то у него свои ограничения и соответственно не всегда можно лего заменить им стандартный массив. А вот замечание alexalexes про передачу по ссылке, чтобы не копировать весь массив, наверное более часто можно встретить. Опять же, если знать как php работает с памятью и помнить про copy-on-write, то и это не всегда нужно.
По ссылке передается только то, что указано передавать по ссылке, в том числе массивы. Объекты хоть и не создаются заново при передаче в переменную, это не тоже самое, что передача по ссылке, там есть свои нюансы.
И, хотя, я не согласен с Ипатьев по поводу php "запустился, поработал долю секунды, завершился", очень часто работал с демонами, которые работают неограниченно долго. Но, согласен, вопрос "на стеке или в куче" для php не столь актуален. Хотя теоретически вопрос очень интересный, насколько знаю, с 7 версии zval хранятся именно в стеке, но не смогу рассказать подробно как организуется хранение, сам хочу поизучать вопрос.

Answer 2

[Владимир Коротенко]

Существенная . Насчет памяти в PHP https://habr.com/ru/company/otus/blog/582442/
И что касается исполнения. NET запускается как процесс выполняет что то на старте, возможно создает пул соединений, заполняет буфера, по ходу работы оптимизирует код в рантайме.

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

Comments

[Ипатьев]

Ээээ... вообще-то, эта статья совсем про другое

[Vitsliputsli]

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

совсем не так, когда речь идет о fpm, разве что в cli так, и то, там можно включить кеширование байт-кода.

[Владимир Коротенко]

Vitsliputsli, так закиньте человеку статью. Я в общем то только про С# могу адекватно ответить.

Насколько я понимаю процесс fpm подключает все модули к себе в память и при первом запросе сохраняет опкоды в /tmp/.opcodes
Дальше только форкает себя

[Vitsliputsli]

Владимир Коротенко, автору это не нужно, он спрашивает совсем о другом.

Answer 3

[AgentSmith72]

Адреса памяти бесполезны в PHP-скриптах, поскольку интерпретатор обрабатывает всю внутреннюю переменную.

Работа с памятью: "Разделяемая память" но об этом джуна точно не спросят.

Работа с очередью
Работа со структурами данных итераторов

Для повышения уровня понимания, как эта самая внутренняя переменная создаётся: JIT в PHP 8

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

Comments

[Ипатьев]

во-первых, генераторы для экономии памяти совершенно не обязательны.
во-вторых, если выгружать из БД миллион строк, то никакие генераторы не помогут
и в-третьих, самое главное в экономии памяти - это не выгружать из БД сразу миллион строк, а запрашивать ровно столько, сколько нужно.

[Ипатьев]

Да, кстати, и при чем тут JIT?
Вы вопросом не ошиблись?

[AgentSmith72]

Ипатьев, согласен с вами полностью. Цель примера про генераторы показать один из способ, контроля памяти.

[Ипатьев]

Ещё раз: генераторы не занимаются "контролем памяти"
Они помогают писать более красивый код.
Недавно статья была на Хабре на эту тему.

[AgentSmith72]

Ипатьев, человек джуном хочет быть, но не имеет понимания, как устроен php. В этой статье подробно описано устройство php.

[Ипатьев]

В этой статье описано, как устроен JIT. Который в 99% случаев бесполезен чуть менее, чем полностью.
про то, как устроен РНР, в статье нет почти ничего
а про память, про которую он спрашивал - нет ничего вообще.
JIT работает с кодом, к памяти он вообще никакого отношения не имеет

[AgentSmith72]

Ипатьев, нет времени спорить. Жмите на ссылку про генераторы: 27:10 таймкод.

[Ипатьев]

AgentSmith72 не нужно мне тыкать всякими видео. Варианта тут два: либо автор - инфоцыган, который сам не понимает, о чём говорит, либо это вы не поняли, о чём там говорится.

[AgentSmith72]

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

[Ипатьев]

Посмотрел видео. Автор говорит правильные вещи.
Таймкод 21:00
Он говорит ровно то, что написано выше у меня: генераторы помогают писать более красивый код.
"Мы хотим отделить выборку из БД от бизнес логики". Именно! Это именно то, для чего используются генераторы.
А про память - "чуть хуже, чем предыдущий метод" без генераторов.

[AgentSmith72]

Ипатьев, так уж и быть, объясню профессионалу основы php:

Генераторы представляют собой простой механизм для циклической обработки данных, БЕЗ НЕОБХОДИМОСТИ СОЗДАВАТЬ МАССИВ ДАННЫХ В ПАМЯТИ

Без необходимости создавать массив в памяти - это значит, что мы контролируем память.

Скорее всего, вы не освоили данный подход, а в интернете тем временем полно статей где связаны слова "Генератор + память".

“Yield” и деликатная работа с памятью в PHP
Увеличение производительности памяти при помощи Ge...

Ну и на последок, статья от VC team:
Функциональное программирование с PHP-генераторами

Цитата из статьи:

В нашем гипотетическом мире в день может быть от 100 до 1 000 000 000 заказов, так что мы не можем просто получить их все у API без того, чтобы нам выставили огромный счёт за сервер, способный одновременно хранить заказы в памяти. Давайте создадим генератор для ленивого извлечения заказов из Storeify API по мере необходимости.

Предположу что вы не работали с большими данными по API.

[Ипатьев]

Вы всё не унимаетесь :)
В интернете действительно много статей, в которых "связаны слова Генератор + память". Но это не значит, что им надо слепо верить.
Эти две статьи написаны как раз инфоцыганами. С первой всё ясно, просто почитайте комментарии.
Во второй на самом деле ещё смешнее. Мало того, что автор - обычный шулер, который выдаёт обычный цикл перебором за какие-то уникальные особенности генератора. Но кроме этого, пытаясь высосать из пальца пример экономии памяти, он пишет код сложностью O(n2). Причём, как голубой воришка, стыдливо замечает, "Немного затратно постоянно перечитывать каждый кусок данных". То есть для него миллион раз прочитать файл в миллион строк - это "немного затратно" :)))

Поймите же уже наконец. В отличие от вас, я эти статьи читал в оригинале, и проорался с них, когда они только появились. А не нагуглил поспешно переводы, даже не заглянув внутрь.
Давайте договоримся, если мы продолжаем разговор, то говорим предметно, а не ссылками.
Впрочем, если вы хотите ссылок, то я сейчас найду специально для вас

[AgentSmith72]

Ипатьев, а что насчёт статьи от VC team, про перекачку большого объёма записей по API?

[Ипатьев]

Вот, https://habr.com/ru/post/599113/
Хотя эта ссылка по сути и не нужна - Андрей Шестаков в вашем же видео говорит ровно то же самое. Что генераторы не про экономию памяти, а про рациональный код. Посмотрите его уже наконец :)

[Ипатьев]

а что насчёт статьи от VC team, про перекачку большого объёма записей по API?

Давайте ссылку, посмотрим и на неё.

[AgentSmith72]

Ипатьев, Функциональное программирование с PHP-генераторами

Цитата из статьи:
В нашем гипотетическом мире в день может быть от 100 до 1 000 000 000 заказов, так что мы не можем просто получить их все у API без того, чтобы нам выставили огромный счёт за сервер, способный одновременно хранить заказы в памяти. Давайте создадим генератор для ленивого извлечения заказов из Storeify API по мере необходимости.

[Ипатьев]

Судя по всему, речь вот об этом https://habr.com/ru/company/vk/blog/351818/

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

Я оригинал раньше не видел, но статья построена по известной схеме, которая сводится к "по отдельности забирает объекты из API" - вот буквальная цитата.
То есть буквально весь смысл статьи - это "если надо экономить память, то надо не забирать сразу 200 тыщ миллионов строк из API, а забирать по одному". Прямо вселенская мудрость, без этой статьи никто бы не догадался.

Суть статьи не в том, как экономить память, а в том, как делать конвейеры с помощью генераторов. про функциональное программирование. Когда фактически вся программа - это вложенные вызовы функций.
А задача экономии памяти решается стандартно - выборкой элементов по одному в цикле. А уж явный это цикл - или завёрнутый в генератор - дело десятое.

[Ипатьев]

Даже, наверное так: в функциональном программировании генераторы действительно позволяют экономить память. Потому что надо результат работы одной функции передавать на вход другой.
Но опять же - это проблема функционального программирования, а не "работы с большими данными по API".

Ну смешно же, ей-богу.
Генераторы придумали лет 10 назад.
А до тех пор что - без вариантов, "с большими данными по api" работать было нельзя? Серьёзно?
Ну вот зачем смешивать два понятия - работу с большими данными перебором и генераторы?
Внутри генератора тот же самый цикл. Код работы с API в этой статье - это обычный do .. while:

$limit = 20;
$requestParams = [
  'lastUpdatedAfter' => new DateTime('yesterday'),
  'limit' => $limit,
  'offset' => 0
];
$orders = [];

do {
    // Grab a batch of orders from Storeify and yield from that list.
    $orders = Storeify::getOrders($requestParams);

    $requestParams['offset'] += $limit;
} while (!empty($orders));

А генератор, как уже говорилось выше, позволяет завернуть этот цикл в функцию и передать куда-то дальше.
То есть память нам экономит старый добрый принцип "читать по одному".