Нужно ли удалять переменные если скрипт заканчивается exit 'ом

[AmdY]

@HORO Дело том, что твой unset не даёт гарантированной очистки памяти. А в случае окончания скрипта или exit, это вообзе бесмылсенно, так как помять сама почистится. Помнится была статья на тему, что с unset скорость скрипта наоборот падает.

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

 

[HORO]

Как это unset не дает гарантированной очистки памяти? И я не говорил что нужно каждую переменную удалять и про exit ничего не писал.
Конечно скорость падает, ведь время уходит на удаление данных из памяти (спичечная часть времени), зато уменьшается её потребление. Это особенно актульно при работе с php массивами.

Ещё раз, я написал что оптимально очищать память после использования, особенно от больших переменных, это не спичечная оптимизация (ну если не смотреть со стороны выделенного сервака)

 

[fixxxer]

Все, что делает unset - декрементит refcount. Ровно это же происходит при выходе из скоупа.

Смысл делать явный unset есть только с нелокальными переменными и/или циклическими ссылками.

 

[HORO]

И при refcount=0 сборщик будет вызван только на выходе?

 

[fixxxer]

При refcount=0 память освободится (а точнее - пометится свободной) практически моментально. Ты можешь этого не заметить, потому что php достаточно умен, чтобы выделять память относительно крупными блоками, а не на каждый байт елозить.

 

[grigori]

Он просил пример использования header в роли echo/print, для вывода.

все-равно не понимаю.
зачем специальные конструкции языка использовать не по назначению?
просто чтобы доказать что это сложно и что это делать не надо?

 

[HORO]

При refcount=0 память освободится (а точнее - пометится свободной) практически моментально. Ты можешь этого не заметить, потому что php достаточно умен, чтобы выделять память относительно крупными блоками, а не на каждый байт елозить.

и в этот самый момент эта память перейдет к скрипту который в ней нуждается, а если нет, то очистится GC, так?

 

[c0dex]

все-равно не понимаю.
зачем специальные конструкции языка использовать не по назначению?
просто чтобы доказать что это сложно и что это делать не надо?

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

 

[AnrDaemon]

и в этот самый момент эта память перейдет к скрипту который в ней нуждается, а если нет, то очистится GC, так?

Нет. См. выше, память выделяется блоками, а GC вообще работает раз в год по обещанию. (Читай - когда больше нечем заняться.)
Мораль в том, что не надо заниматься ерундой.
unset()'ить имеет смысл только данные, влияющие на безопасность приложения, и циклические ссылки. И то - вопрос, действительно ли оно тебе надо… если всё равно само убьётся через пару микросекунд.

 

[grigori]

мда. вот как сознание-то работает.
я не писал о равнозначности, но, видимо, надо было писать иначе, раз это так воспринято.
это как samdark как-то написал в статье, что удаление индексов в определенных ситуациях при записи больших объемов повышает скорость работы с базой данных, а мне на собеседовании чувак заявляет: "мы при выкладке все индексы дропаем нафиг, для скорости - Макаров так написал".

не надо меня подлавливать я хотел обосновать, что header() - это функция вывода, и через fwrite() ее можно эмулировать

 

[флоппик]

мя хотел обосновать, что header() - это функция вывода, и через fwrite() ее можно эмулировать

fwrite(STDOUT, 'Content-type:text-plain'. "\r\n");

Не?

 

[HORO]

Нет. См. выше, память выделяется блоками, а GC вообще работает раз в год по обещанию. (Читай - когда больше нечем заняться.)
Мораль в том, что не надо заниматься ерундой.
unset()'ить имеет смысл только данные, влияющие на безопасность приложения, и циклические ссылки. И то - вопрос, действительно ли оно тебе надо… если всё равно само убьётся через пару микросекунд.

круто. Тоесть я выделил 100Мб в начале скрипта, потом unset и завис на N минут, и все память утекла? ))

 

[grigori]

http://php.net/manual/ru/features.gc.php

 

[grigori]

fwrite(STDOUT, 'Content-type:text-plain'. "\r\n");

Не?

это ты в лог запишешь, если в fpm настроен отлов системного вывода

 

[AnrDaemon]

fwrite(STDOUT, 'Content-type:text-plain'. "\r\n");

Не?

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

 

[grigori]

AnrDaemon, что ты можешь привести кроме своего личное мнения? Отсылок на документацию в подтверждение тезиса отдельной концепции ты не приведешь, там этого нет.
Вот контр-аргумент: идеологически в юниксе взаимодействие с файлами, сетью, сокетами и устройствами строится на базе общего ABI.
Все строится на потоках. PHP - часть юникс-инфраструктуры. "PHP - это клей", - Размус Лендорф. Обертка над библиотеками и потоками ввода-вывода.

 

[fixxxer]

Как минимум в apache sapi (и, полагаю, во всех webserver module sapi) отправка заголовков - это вызов отдельных апачевых api-функций, ога.

В случае (fast)cgi все сводится к банальной записи в stdout/сокет, да.

это ты в лог запишешь, если в fpm настроен отлов системного вывода

не, это если stderr же.

 

[grigori]

http://php.net/manual/en/wrappers.php.php
STDOUT и STDERR - это, вообще, константы, которые объявлены в cli, а в остальных используется php://stdout и php://stderr
fastcgi читает не из stdout, а из своего специального канала

в fpm.conf есть директива catch_workers_output
если ее включить, вывод обоих каналов fpm-процессов будет записан в error_log

; Redirect worker stdout and stderr into main error log. If not set, stdout and
; stderr will be redirected to /dev/null according to FastCGI specs.
; Note: on highloaded environement, this can cause some delay in the page
; process time (several ms).
; Default Value: no
;catch_workers_output = yes

 

[fixxxer]

А, точно.

Но я помню, что можно только stderr. Либо чота вроде catch_workers_output = stderr, либо в старых версиях только stderr редиректился. Вот прям уверен, что было, вряд ли "ложная память" )

А STDOUT/STDERR это на самом деле в итоге тупо 1 и 2, если внутрь посмотреть

 

[флоппик]

А, точно.
Но я помню, что можно только stderr. Либо чота вроде catch_workers_output = stderr, либо в старых версиях только stderr редиректился. Вот прям уверен, что было, вряд ли "ложная память" )

Да, было такое, до того как он стал частью пхп. То бишь, очень давно.