Нужно ли стремиться обнулять переменные и по возможности не создавать их копий в проектах php?

Question

[Слава]

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

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

$lessons = $school['lessons'];

foreach ($lessons as $lesson) { ...}

или желательно таки писать foreach ($school['lessons'] as $lesson) { ... }
Ведь когда мы создаем переменную, то в нее копируется значение другой переменной и мы работаем с копией, а это дорогая операция в плане временных затрат и затрат памяти.

Ну и по выходу из цикла делать $lessons = null или unset($school['lessons']

или в php принято не заморачиваться?

Answer 1

[Melkij]

Ведь когда мы создаем переменную, то в нее копируется значение другой переменной и мы работаем с копией

Неа. См. zval

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

Разве компилятор go недостаточно умён для элементарных оптимизаций кода?
Вы проверяли байткод, ваша оптимизация действительно имеет место или это самообман?

Comments

[Слава]

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

[Василий Банников]

Слава, копия массива - это одно.
Копия ссылки на массив - это другое.

[Vitsliputsli]

Слава, в php используется механизм Copy-On-Write, когда вы присваиваете новой переменной значение старой, то значение не копируется, а создается ссылка (почти такая, как если бы вы вручную указали ссылку), и только в момент когда вы начнете изменять новую переменную произойдет копирование значения. Т.е. если значения не менять, то все расходы - 16 байт, неважно для какого значения.
Касательно удаления, то разумеется лучше делать unset, чтобы и значения и сама переменная были очищены. Чаще всего в этом нет нужды, т.к. переменные живут внутри функций или объектов и будут уничтожены при их завершении или уничтожении. Да, и чистка произойдет тогда, когда запустится мусорщик, поэтому если вы не выполняете долгих расчетов с большим кол-во данных внутри одного объекта, особой нужды делать unset нет.

[Слава]

Vitsliputsli, спасибо за ценную информацию. как они хитро придумали касательно copy-on-write.

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

[Ипатьев]

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

Answer 2

[Adamos]

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

Comments

[Виктор Кожухарь]

Совершенно верно. В PHP от нас сознательно скрыли указатели, чтобы программисты этим не заморачивались, как в C. Поэтому разработчики языка постоянно решают такие вопросы за нас. Думаю, если бы они оставили нам всю прелесть работы с указателями, строгую типизацию и т.д., то PHP вряд ли стал бы настолько популярным языком.

[Adamos]

Виктор Кожухарь, если бы он(и) оставил(и) все эти прелести, третий Java / С# никому бы в хрен не уперся.
Пустовала как раз ниша скриптов на пять строчек, для написания которых не нужно тренировать клингонский.
Это уже потом пых эту нишу распер до половины интернета.

[tukreb]

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

[Vitsliputsli]

Виктор Кожухарь, вряд ли чтобы "не заморачивались", указатели в языке с динамической типизацией бессмысленны. Если указатель будет указывать на значение, то непонятно что с ним делать без типа, т.е. без zval. А если ссылаться на zval, то его нужно обрабатывать, а это уже не указатель.