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

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

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

$lessons = $school['lessons'];  foreach ($lessons as $lesson) { ...}

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

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

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

Дополнительно:

Ответы:

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

Неа. См. zval

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

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

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

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

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

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

• Совершенно верно. В PHP от нас сознательно скрыли указатели, чтобы программисты этим не заморачивались, как в C. Поэтому разработчики языка постоянно решают такие вопросы за нас. Думаю, если бы они оставили нам всю прелесть работы с указателями, строгую типизацию и т.д., то PHP вряд ли стал бы настолько популярным языком.
• Виктор Кожухарь, если бы он(и) оставил(и) все эти прелести, третий Java / С# никому бы в хрен не уперся.
  Пустовала как раз ниша скриптов на пять строчек, для написания которых не нужно тренировать клингонский.
  Это уже потом пых эту нишу распер до половины интернета.
• Виктор Кожухарь, строгая типизация возвращается вообще то:) Все последние фреймворке почти завершили переход на типизацию.
• Виктор Кожухарь, вряд ли чтобы "не заморачивались", указатели в языке с динамической типизацией бессмысленны. Если указатель будет указывать на значение, то непонятно что с ним делать без типа, т.е. без zval. А если ссылаться на zval, то его нужно обрабатывать, а это уже не указатель.