Комментарии 90
That's it, I'm moving to Python =)
и смысл таких комментариев?
Очень тонко.
Пистон малопригоден для целей, для которых предназначен PHP
Да, ломать разработчику мозг, путая извилины, и приучая говнокодить путем постоянной демонстрации мегатонн уже написанных спагетти, питон действительно непригоден.
Спасибо, интересно и познавательно!
Интересно, заприметил один новый момент для себя. Было бы неплохо написать еще одну статью по работе с объектами, чтобы было все в одном месте (на хабре), а не разбросано по интернету.
Еще всегда задавался вопросом, почему подобные вещи не пишут в книжках аля «учебники по PHP для профессионалов»?! По крайней мере я держал в руках пару подобных книжек (одна из них была увесистой, страниц в 500) и не помню, чтобы там были затронуты подобные моменты оптимизации.
Еще всегда задавался вопросом, почему подобные вещи не пишут в книжках аля «учебники по PHP для профессионалов»?! По крайней мере я держал в руках пару подобных книжек (одна из них была увесистой, страниц в 500) и не помню, чтобы там были затронуты подобные моменты оптимизации.
Ой, очень интересуюсь подобной литературой (аля «учебники по PHP для профессионалов»). Не подскажите, что за книги? Можно и не по PHP — C/C++, JAVA, Windows & Linux programming, Windows, Linux… тоже вполне подойдут — хоть сюда, хоть в личку.
PS А как Вы «елочки» ставите, неужели через Alt или Copy&Paste? )
PS А как Вы «елочки» ставите, неужели через Alt или Copy&Paste? )
«Ёлочки» тут Хабр сам ставить умеет. А вообще их все обычно вводят при помощи кастомных раскладок, вроде бирманской, она и другие расхожие типографические символы позволяет проще вводить.
Ёлочки в Windows:
« ALT (зажать) + 0171 (на цифровой клавиатуре)
» ALT + 0187
Аналогично можно и другие символы вставлять
« ALT (зажать) + 0171 (на цифровой клавиатуре)
» ALT + 0187
Аналогично можно и другие символы вставлять
Ещё можно запустить charmap в Windows или Gnome'овский gucharmap в Linux, и там выбрать нужные символы. Не помню, как там в виндовской утилите, но в линуксовой можно выбирать символы из Unicode-категорий типа «Mathematical operators» и т.п. Очень удобно, я считаю.
Класс, теперь я знаю как вставлять дробь ½ ¼ и писать вот такие знаки ¿ █ “ ”
В общем спасибо надо подучить.
В общем спасибо надо подучить.
Хм. Не посмотрев ссылку задался вопросом — неужели в Бирме настолько развиты компьютерные технологии.
Ёлочки в Mac OS:
« — Alt + ъ
» — Alt + Shift + ъ
« — Alt + ъ
» — Alt + Shift + ъ
>почему подобные вещи не пишут в книжках
потому что не нужно? на мое имхо вот это все надо в 2% случаев, и то надо сильно подумать перед тем как лезть в эти дебри, а не просто поставить лимит побольше. php скрипт работает доли секунды, потом завершается. Даже в режиме FASTCGI где это ОЧЕНЬ сильно не нужно.
а так, тут просто собрание коллекции фактов, без выводов.
на мое имхо вся эта статья умещается в одну фразу «copy on write». Знание значения этой фразы заменяет всю эту статью.
НЕ рассмотрен сборщик мусора в разных версиях, а это самое интересное.
НЕ рассмотренно сколько памяти аллокированно скриптом и отдается ли она системе. а то у особо везучих получается веселая вещь — вроде mem usage показывает ноль, а скрипт отваливается по нехватке памяти.
>Таким образом PHP действительно избавляет от необходимости использовать передачу по >ссылке для оптимизации использования памяти
вот тут самое смешное то, что передача по ссылке если внутри функции переменная не меняется УХУДШАЕТ быстродействие
>В остальном же мы видим, что если массив, используемый для цикла, имеет больше чем одну >ссылку на себя, тогда для него не применяется оптимизация из примера №1
опять — а скорость померять? а количество zval'ов посмотреть?
потому что не нужно? на мое имхо вот это все надо в 2% случаев, и то надо сильно подумать перед тем как лезть в эти дебри, а не просто поставить лимит побольше. php скрипт работает доли секунды, потом завершается. Даже в режиме FASTCGI где это ОЧЕНЬ сильно не нужно.
а так, тут просто собрание коллекции фактов, без выводов.
на мое имхо вся эта статья умещается в одну фразу «copy on write». Знание значения этой фразы заменяет всю эту статью.
НЕ рассмотрен сборщик мусора в разных версиях, а это самое интересное.
НЕ рассмотренно сколько памяти аллокированно скриптом и отдается ли она системе. а то у особо везучих получается веселая вещь — вроде mem usage показывает ноль, а скрипт отваливается по нехватке памяти.
>Таким образом PHP действительно избавляет от необходимости использовать передачу по >ссылке для оптимизации использования памяти
вот тут самое смешное то, что передача по ссылке если внутри функции переменная не меняется УХУДШАЕТ быстродействие
>В остальном же мы видим, что если массив, используемый для цикла, имеет больше чем одну >ссылку на себя, тогда для него не применяется оптимизация из примера №1
опять — а скорость померять? а количество zval'ов посмотреть?
Если у вас есть что сказать — напишите свою статью, в которой раскроете эти более интересные факты.
И я считаю, что это, все же, нужно знать. Если вы думаете иначе — не стоит читать такие статьи :)
И я считаю, что это, все же, нужно знать. Если вы думаете иначе — не стоит читать такие статьи :)
1. Насчет 2% случаев это очень условно. Если человек пишет только мини-скрипты «на коленке», тогда конечно да. Если же приложения по-серьезнее, то учитывать такие моменты придется уже не в 2% случаев, а например в каждом скрипте, где есть обработка данных из БД.
Я сам был бы рад узнать всё это из книг, но к сожалению мне таковые не встречались пока.
2. Не совсем понимаю каких именно выводов вы ожидали? Сколько ситуаций — столько и выводов. Здесь важен именно механизм, а применять ли его и как именно — это уже вопрос конкретной ситуации.
3. Я не стремился впихнуть абсолютно всё в одну статью, да и сама статья называется «Работа с памятью», а не «Как PHP управляет памятью». Согласитесь, что это немного разные вещи. И хотя сборщик мусора и важная вещь, но если не считать редкие случаи использования коллектора циклических ссылок в 5.3, то вы практически никогда не будете использовать его сами напрямую в скрипте.
4. Использование памяти скриптом, а именно аллокация при старте и последующей работе, в очень значительной мере зависит от самой OS, интерпретатора и их настроек. Это уже не только вопрос работы с памятью в скрипте, а гораздо более широкое понятие со множеством уникальных случаев. И данная тема также не является предметом данной статьи.
5. Насчет ухудшения быстродействия хотелось бы увидеть от вас пример или ссылочку. Если я ничего не путаю, то передача по ссылке просто изменяет значения refcount__gc и is_ref__gc в _zval_struct. Не уверен что это как-то значительно скажется на быстродействии, если вообще скажется.
6. Посмотрите в пример внимательнее. Там прекрасно видно когда выделяется новая память, а когда используются ссылки. Если вы считаете что это не говорит о количестве новых zval контейнеров и и переменных, тогда было бы замечательно увидеть от вас пример, что это не соответствует действительности и приводит к потере скорости. Полагаю что многим было бы интересно прочитать про найденный вами баг, поправлю статью при необходимости. Касательно скорости опять же не совсем понимаю где должна произойти ее потеря, если речь идет только об изменении счетчиков ссылок.
В целом же по вашему комментарию можно сказать, что вы знаете что-то, что очень было интересно многим прочитать. Было бы интересно увидеть от вас статью на указанные вами темы.
Я сам был бы рад узнать всё это из книг, но к сожалению мне таковые не встречались пока.
2. Не совсем понимаю каких именно выводов вы ожидали? Сколько ситуаций — столько и выводов. Здесь важен именно механизм, а применять ли его и как именно — это уже вопрос конкретной ситуации.
3. Я не стремился впихнуть абсолютно всё в одну статью, да и сама статья называется «Работа с памятью», а не «Как PHP управляет памятью». Согласитесь, что это немного разные вещи. И хотя сборщик мусора и важная вещь, но если не считать редкие случаи использования коллектора циклических ссылок в 5.3, то вы практически никогда не будете использовать его сами напрямую в скрипте.
4. Использование памяти скриптом, а именно аллокация при старте и последующей работе, в очень значительной мере зависит от самой OS, интерпретатора и их настроек. Это уже не только вопрос работы с памятью в скрипте, а гораздо более широкое понятие со множеством уникальных случаев. И данная тема также не является предметом данной статьи.
5. Насчет ухудшения быстродействия хотелось бы увидеть от вас пример или ссылочку. Если я ничего не путаю, то передача по ссылке просто изменяет значения refcount__gc и is_ref__gc в _zval_struct. Не уверен что это как-то значительно скажется на быстродействии, если вообще скажется.
6. Посмотрите в пример внимательнее. Там прекрасно видно когда выделяется новая память, а когда используются ссылки. Если вы считаете что это не говорит о количестве новых zval контейнеров и и переменных, тогда было бы замечательно увидеть от вас пример, что это не соответствует действительности и приводит к потере скорости. Полагаю что многим было бы интересно прочитать про найденный вами баг, поправлю статью при необходимости. Касательно скорости опять же не совсем понимаю где должна произойти ее потеря, если речь идет только об изменении счетчиков ссылок.
В целом же по вашему комментарию можно сказать, что вы знаете что-то, что очень было интересно многим прочитать. Было бы интересно увидеть от вас статью на указанные вами темы.
Насчет ухудшения быстродействия хотелось бы увидеть от вас пример или ссылочку
function a1(array $a){
echo count($a);
}
function a2(array &$a){
echo count($a);
}
$a = array(1,2,3,4,5,6,7,8,9,0)
a1($a);
a2($a);
какая функция будет быстрее и почему?
function a1(array $a){
echo count($a);
}
function a2(array &$a){
echo count($a);
}
$a = array(1,2,3,4,5,6,7,8,9,0)
a1($a);
a2($a);
какая функция будет быстрее и почему?
Интересный у вас подход. Сами сделали утверждение и просите других, чтобы вас убедили и предоставили вам доказательства )
Я уже написал вам: «Не уверен что это как-то значительно скажется на быстродействии, если вообще скажется.»
И тем не менее сделаю вам одолжение:
Оборачиваем ваш пример в код для отладки и проверки памяти.
Смотрим xdebug_debug_zval('a'); внутри вызова функции:
в случае с function a1(array &$a) получаем
a: (refcount=3, is_ref=1)=array (… )
в случае с function a2(array $a) получаем
a: (refcount=3, is_ref=0)=array (… )
Единственное изменение, это индикатор ссылки-переменной в одном случае =1, в другом =0, что логично.
В обоих случаях потребление памяти одинаковое, так как никаких действий с массивом в ваших примерах не производится (имеется ввиду изменение значений) следовательно и копирования с выделением памяти не произойдет.
Вы действительно хотите найти существенную разницу в производительности между конкретно двумя этими функциями только из-за передачи значения по ссылке или через оптимизированное копирование?
Давайте даже посмотрим OpCode двух этих функций:
Через копирование: www.heypasteit.com/clip/05DW
Через ссылку: www.heypasteit.com/clip/05DX
Разница между двумя опкодами только: в 7-ой строке SEND_VAR или SEND_REF
Если у вас есть желание, можете копнуть еще глубже (тут уже только в С код) и найти всё же те различия, о которых говорите.
Я уже написал вам: «Не уверен что это как-то значительно скажется на быстродействии, если вообще скажется.»
И тем не менее сделаю вам одолжение:
Оборачиваем ваш пример в код для отладки и проверки памяти.
Смотрим xdebug_debug_zval('a'); внутри вызова функции:
в случае с function a1(array &$a) получаем
a: (refcount=3, is_ref=1)=array (… )
в случае с function a2(array $a) получаем
a: (refcount=3, is_ref=0)=array (… )
Единственное изменение, это индикатор ссылки-переменной в одном случае =1, в другом =0, что логично.
В обоих случаях потребление памяти одинаковое, так как никаких действий с массивом в ваших примерах не производится (имеется ввиду изменение значений) следовательно и копирования с выделением памяти не произойдет.
Вы действительно хотите найти существенную разницу в производительности между конкретно двумя этими функциями только из-за передачи значения по ссылке или через оптимизированное копирование?
Давайте даже посмотрим OpCode двух этих функций:
Через копирование: www.heypasteit.com/clip/05DW
Через ссылку: www.heypasteit.com/clip/05DX
Разница между двумя опкодами только: в 7-ой строке SEND_VAR или SEND_REF
Если у вас есть желание, можете копнуть еще глубже (тут уже только в С код) и найти всё же те различия, о которых говорите.
>php test.php 1 1000000
524288 524288 335936 335936 1.672581911087
>php test.php 2 1000000
524288 524288 335936 335936 0.5970458984375
524288 524288 335936 335936 1.672581911087
>php test.php 2 1000000
524288 524288 335936 335936 0.5970458984375
То есть, если я правильно понял этот набор цифр, вы предлагаете только ради экономии в 1 секунду на миллион вызовов функции count() везде применять передачу по значению?
Кстати если вы уберете count() из функции, и скажем замените какой-либо операцией вроде $b = strval($a[0]);, то разница исчезнет, так что даже ваша секунда скорее всего просто связана с тем, как count работает со ссылками и значениями, а вовсе не с передачей ссылки или значения в функцию.
Кстати если вы уберете count() из функции, и скажем замените какой-либо операцией вроде $b = strval($a[0]);, то разница исчезнет, так что даже ваша секунда скорее всего просто связана с тем, как count работает со ссылками и значениями, а вовсе не с передачей ссылки или значения в функцию.
>Использование памяти скриптом, а именно аллокация при старте и последующей работе, в очень >значительной мере зависит от самой OS, интерпретатора и их настроек
>И хотя сборщик мусора и важная вещь, но если не считать редкие случаи использования коллектора >циклических ссылок в 5.3
вы не правы.
выделяем 2/3 доступной памяти в переменную
делаем ансет этой переменной
выделяем 2/3 памяти в другую переменную
отваливаемся с Allowed memory size exhauste
bugs.php.net/bug.php?id=53031
>И хотя сборщик мусора и важная вещь, но если не считать редкие случаи использования коллектора >циклических ссылок в 5.3
вы не правы.
выделяем 2/3 доступной памяти в переменную
делаем ансет этой переменной
выделяем 2/3 памяти в другую переменную
отваливаемся с Allowed memory size exhauste
bugs.php.net/bug.php?id=53031
Пожалуйста, внимательно читайте то, что написано в ссылках, которые вы даете. Первый же комментарий от администрации: [2010-10-09 18:02 UTC] johannes@php.net
"… описанная вами ситуация не является багом. Пожалуйста, прочитайте документацию касательно того, как обрабатываются циклические ссылки de3.php.net/manual/en/features.gc.collecting-cycles.php ...".
"… описанная вами ситуация не является багом. Пожалуйста, прочитайте документацию касательно того, как обрабатываются циклические ссылки de3.php.net/manual/en/features.gc.collecting-cycles.php ...".
я не говорил что это баг. я хотел сказать что не рассмотрена вот такая достаточно тривиальная ситуация, с фатальными последствиями, в которой без принудительного вызова сборщика мусора не обойтись.
это относилось к процитированым фразам
тут
1) использование памяти НЕ зависит от ОС и настроек интерпритатора
2) тут есть сборщик мусора и нет циклических ссылок.
это относилось к процитированым фразам
тут
1) использование памяти НЕ зависит от ОС и настроек интерпритатора
2) тут есть сборщик мусора и нет циклических ссылок.
и — это опровергает ваш ваш вывод:
>Как видите, переменная не была полностью уничтожена. Под нее остается выделенным еще >76 байт.
>Как видите, переменная не была полностью уничтожена. Под нее остается выделенным еще >76 байт.
Может поясните, каким это образом это опровергает?
В вопросе программирования я как бы привык доверять больше цифрам, нежели умозрительным заключениям. Пока же цифры показывают, что память остается. И это абсолютно логично, так как переменная не уничтожается, а присваивается null значение (остается zval контейнер и запись об имени переменной).
Хотелось бы увидеть что-то конкретное, иначе это уже смахивает на троллинг )
В вопросе программирования я как бы привык доверять больше цифрам, нежели умозрительным заключениям. Пока же цифры показывают, что память остается. И это абсолютно логично, так как переменная не уничтожается, а присваивается null значение (остается zval контейнер и запись об имени переменной).
Хотелось бы увидеть что-то конкретное, иначе это уже смахивает на троллинг )
о хосподи. в языках со сборщиком мусора память НЕ ОСВОБОЖДАЕТСЯ до вызова (руками или системой) этого самого сборщика.
ссылку на кейс я привел выше. вы же говорите что освобождается. вопрос подтверждаете ли вы этот кейс или нет, и если нет, то что надо сделать?
ссылку на кейс я привел выше. вы же говорите что освобождается. вопрос подтверждаете ли вы этот кейс или нет, и если нет, то что надо сделать?
Прочитайте (еще раз) вот этот комментарий. Измените и еще раз проверьте ваш кейс.
И ответьте на первый вопрос комментария.
Полагаю это разрешит вопрос.
В PHP высвобождается память на основе подсчета ссылок. Если переменная выходит из области видимости, то у нее обнуляется счетчик ссылок и она удаляется. Тоже самое происходит и при unset. Память высвобождается сразу. Так что тут вы не правы. Стандартный сборщик мусора как раз и занимается таким обнулением и очисткой, при выходе из функций, завершении скрипта и т.д. Сборщик циклических ссылок занимается этим только при переваливании числа ссылок за 10000 или же при ручном вызове.
Если бы всё было идеально так как вы говорите, тогда бы налицо был виден баг в отображении информации потребления памяти через memory_get_usage(), и мы бы видели эти утечки, или «задержки обработки сборщика мусора».
И ответьте на первый вопрос комментария.
Полагаю это разрешит вопрос.
В PHP высвобождается память на основе подсчета ссылок. Если переменная выходит из области видимости, то у нее обнуляется счетчик ссылок и она удаляется. Тоже самое происходит и при unset. Память высвобождается сразу. Так что тут вы не правы. Стандартный сборщик мусора как раз и занимается таким обнулением и очисткой, при выходе из функций, завершении скрипта и т.д. Сборщик циклических ссылок занимается этим только при переваливании числа ссылок за 10000 или же при ручном вызове.
Если бы всё было идеально так как вы говорите, тогда бы налицо был виден баг в отображении информации потребления памяти через memory_get_usage(), и мы бы видели эти утечки, или «задержки обработки сборщика мусора».
Решил всё-таки найти в документации.
Почитайте: de3.php.net/manual/ru/features.gc.refcounting-basics.php
Особенно смотрим вот это:
«Как только „refcount“ станет равным нулю, контейнер уничтожается. „refcount“ уменьшается на единицу при уходе переменной из области видимости (например, в конце функции) или при вызове unset() с данной переменной.
Если мы сейчас вызовем unset($a);, то контейнер, включая тип и значение, будет удален из памяти.»
Ну или мы налицо имеем баг документации PHP.
Если я что-то упустил и что-то не так понимаю — подскажите где почитать.
Почитайте: de3.php.net/manual/ru/features.gc.refcounting-basics.php
Особенно смотрим вот это:
«Как только „refcount“ станет равным нулю, контейнер уничтожается. „refcount“ уменьшается на единицу при уходе переменной из области видимости (например, в конце функции) или при вызове unset() с данной переменной.
Если мы сейчас вызовем unset($a);, то контейнер, включая тип и значение, будет удален из памяти.»
Ну или мы налицо имеем баг документации PHP.
Если я что-то упустил и что-то не так понимаю — подскажите где почитать.
bugs.php.net/bug.php?id=53031
здесь. подтверждаете ли вы этот кейс или нет?
здесь. подтверждаете ли вы этот кейс или нет?
Как только „refcount“ станет равным нулю, контейнер уничтожается. „refcount“ уменьшается на единицу при уходе переменной из области видимости (например, в конце функции) или при вызове unset() с данной переменной.
плохо читали:
To avoid having to call the checking of garbage cycles with every possible decrease of a refcount…
Only when the root buffer is full does the collection mechanism start for all the different zvals inside. See step A in the figure above.
плохо читали:
To avoid having to call the checking of garbage cycles with every possible decrease of a refcount…
Only when the root buffer is full does the collection mechanism start for all the different zvals inside. See step A in the figure above.
Во первых, указывайте откуда вы берете цитаты.
В данном случае это цитата отсюда: php.net/manual/en/features.gc.collecting-cycles.php
Это касается описания сборщика мусора для ЦИКЛИЧЕСКИХ ССЫЛОК, который появился в 5.3, а не обычного сборщика мусора PHP, про который я писал вам.
Это два разных сборщика мусора.
Да вашей цитате есть очень важное слово: Only when the root buffer is full does the collection mechanism start for all the different zvals inside.
Сборщик циклических ссылок запускается когда заполняет буфер «корневых ссылок».
Вы начинаете путать одно с другим.
В данном случае это цитата отсюда: php.net/manual/en/features.gc.collecting-cycles.php
Это касается описания сборщика мусора для ЦИКЛИЧЕСКИХ ССЫЛОК, который появился в 5.3, а не обычного сборщика мусора PHP, про который я писал вам.
Это два разных сборщика мусора.
Да вашей цитате есть очень важное слово: Only when the root buffer is full does the collection mechanism start for all the different zvals inside.
Сборщик циклических ссылок запускается когда заполняет буфер «корневых ссылок».
Вы начинаете путать одно с другим.
НЛО прилетело и опубликовало эту надпись здесь
Может быть потому что профессионалы не читают книг «для профессионалов»?
всегда интересовало, почему люди пишут
echo «sutff». PHP_EOL
если можно без конкатенаций (,)?
echo «sutff». PHP_EOL
если можно без конкатенаций (,)?
автоматом чтобы не думать где используется в echo или print или wrapper($str) короче просто привыкли люди что строки сшиваются точкой. пытался однажды с этим бороться — бесполезно.
Вопрос немного в офтоп:
Где можно почитать про оператор «запятая» в PHP? Чисто с т.з. синтаксиса, какое у него поведение.
Где можно почитать про оператор «запятая» в PHP? Чисто с т.з. синтаксиса, какое у него поведение.
Такое же как и остальных местах — перечисление параметров.
Просто именно у echo есть особенность поведения:
echo 'hello ', 'world!';
равносильно:
echo('hello ');
echo('world!');
Это кстати одно из ее отличий от print, который не позволяет такую передачу параметров.
Просто именно у echo есть особенность поведения:
echo 'hello ', 'world!';
равносильно:
echo('hello ');
echo('world!');
Это кстати одно из ее отличий от print, который не позволяет такую передачу параметров.
Ну судя по всему, еще один «костыль» в грамматике.
Интересно, что в мануале запятая заявлена как оператор (в разделе с приоритетами операций), между тем она может быть только частью определенных конструкций.
Интересно, что в мануале запятая заявлена как оператор (в разделе с приоритетами операций), между тем она может быть только частью определенных конструкций.
А к чему бы Вы отнесли запятую?
Отвечу вопросом на вопрос — А к чему бы вы отнесли скобку?
При таком раскладе — просто лексема, для которой существует узкий контекст применимости.
Вопрос мой возник из-за того, что я считал php в большей степени C-style языком. К слову, в Си (и в плюсах, соответственно тоже) запятая — это оператор, возвращающий значение справа.
В JS (можете проверить) это тоже справедливо:
Если говорить про php, то смысл приоритета запятой для меня неясен. Либо документацию писал некомпетентный человек, либо сам язык не имеет дизайна (что объясняет по крайней мере отсутствие официальных спецификаций).
Как кто-то однажды сказал, «Простота — результат глубокого анализа, сложность — результат нагромождения».
При таком раскладе — просто лексема, для которой существует узкий контекст применимости.
Вопрос мой возник из-за того, что я считал php в большей степени C-style языком. К слову, в Си (и в плюсах, соответственно тоже) запятая — это оператор, возвращающий значение справа.
В JS (можете проверить) это тоже справедливо:
var x = (12, 51);
alert(x);Если говорить про php, то смысл приоритета запятой для меня неясен. Либо документацию писал некомпетентный человек, либо сам язык не имеет дизайна (что объясняет по крайней мере отсутствие официальных спецификаций).
Как кто-то однажды сказал, «Простота — результат глубокого анализа, сложность — результат нагромождения».
Потом легко поменять на:
$a = «stuff». PHP_EOL;
А вам придется все запятые заменять.
$a = «stuff». PHP_EOL;
А вам придется все запятые заменять.
Отличный пост! Не знал многие моменты, хотя уже не год программирую на php.
Спасибо за статью. Отметьте только, что фишка с циклом и массивами касается только foreach цикла.
для наглядности не хватает примеров с опкодами
а так статья замечательная
а так статья замечательная
Статья превосходна, спасибо.
Правда я не совсем понимаю, зачем в начале кода два раза подряд использовать $base_memory_usage = memory_get_usage();
Правда я не совсем понимаю, зачем в начале кода два раза подряд использовать $base_memory_usage = memory_get_usage();
Присвоение значения переменной $base_memory_usage добавит лишних 76 байт.
Для удобства просмотра расхода памяти. Первое присвоение создает переменную и выделяет под нее память, но эта память «до» присвоения, второе же присвоение уже содержит объем памяти с учетом переменной $base_memory_usage.
> Получается, что в последней итерации цикла foreach в данном случае потребление массивом памяти возросло в два раза, хотя по самому коду это не очевидно. Но сразу после цикла, потребление памяти вернулось к прежнему значению. Чудеса да и только.
> Причиной тому является оптимизация использования массива в цикле. На время работы цикла, при попытке изменить исходный массив, неявно создается «массив изменений исходного массива» (не копия), который «применяется» к исходному массиву сразу по завершению цикла.
Здесь написана какая-то хрень.
foreach($a as $k => $v) исходный массив копирует полностью при первом изменении (то же самое происходит при любой передаче «по значению» в функцию).
Чтобы этого не было, надо писать foreach($a as $k => &$v)
Но! Копирование массива в php не приводит к deep copy всех его значений, копируется (и дальше изменяется) только его хэш таблица.
Получаем два независимых массива, у которых, тем не менее, память под одинаковые элементы выделяется один раз.
Поэтому overhead от копирования зависит от того, что считать «большим» массивом.
Если это массив из пяти элементов пусть даже по мегабайту каждый, копирование будет почти бесплатным.
Если же это массив вида range(0, 100500), то есть из большого числа мелких элементов, то его копия сожрет куда больше памяти.
proof:
Видно, что на первой итерации цикла копий вообще никаких нет (пока массив мы не меняем), на второй итерации создается полная копия массива $a (foreach продолжает бегать по старой копии) и это съедает сразу много памяти, дальше до конца память постепенно выделяется на zval-ы отдельных заменяемых элементов.
Если заменить последнюю строку на $a[$k] = $a[$k], увидим, что выделения памяти на новые zval больше не будет, но копия массива один раз все равно создастся.
Еще раз размещу ссылку на вот эту замечательную статью, там эти вопросы довольно неплохо разжеваны.
> Причиной тому является оптимизация использования массива в цикле. На время работы цикла, при попытке изменить исходный массив, неявно создается «массив изменений исходного массива» (не копия), который «применяется» к исходному массиву сразу по завершению цикла.
Здесь написана какая-то хрень.
foreach($a as $k => $v) исходный массив копирует полностью при первом изменении (то же самое происходит при любой передаче «по значению» в функцию).
Чтобы этого не было, надо писать foreach($a as $k => &$v)
Но! Копирование массива в php не приводит к deep copy всех его значений, копируется (и дальше изменяется) только его хэш таблица.
Получаем два независимых массива, у которых, тем не менее, память под одинаковые элементы выделяется один раз.
Поэтому overhead от копирования зависит от того, что считать «большим» массивом.
Если это массив из пяти элементов пусть даже по мегабайту каждый, копирование будет почти бесплатным.
Если же это массив вида range(0, 100500), то есть из большого числа мелких элементов, то его копия сожрет куда больше памяти.
proof:
<?php
echo memory_get_usage() . "\n";
$a = range(0, 100500);
echo memory_get_usage() . "\n";
foreach ($a as $k => $v)
{
if ($k == 0 || $k == 1 || $k == 100500) echo memory_get_usage() . "\n";
$a[$k] = 1;
}
Видно, что на первой итерации цикла копий вообще никаких нет (пока массив мы не меняем), на второй итерации создается полная копия массива $a (foreach продолжает бегать по старой копии) и это съедает сразу много памяти, дальше до конца память постепенно выделяется на zval-ы отдельных заменяемых элементов.
Если заменить последнюю строку на $a[$k] = $a[$k], увидим, что выделения памяти на новые zval больше не будет, но копия массива один раз все равно создастся.
Еще раз размещу ссылку на вот эту замечательную статью, там эти вопросы довольно неплохо разжеваны.
Здесь написана какая-то хрень.
foreach($a as $k => $v) исходный массив копирует полностью при первом изменении (то же самое происходит при любой передаче «по значению» в функцию).
Полного копирования не происходит. Посмотрите внимательнее на примеры в статье. Если под «полностью» мы подразумеваем с вами и структуру массива и его значения. Либо мы с вами друг друга не поняли, и тогда прошу вас привести конкретный пример, чтобы было понятнее. Мне интересны ваши доводы.
В остальном ваши замечания справедливы. Не описал в статье явно эту тонкость работы, а именно различие между копированием структуры и копированием значений, что становится существенно при большом числе элементов, а не объеме значений.
С вашего позволения добавлю ссылку в статью и на ваш комментарий, чтобы информация получилась более целостной.
Довод всего лишь в том, что никаких «массивов изменений» в природе не существует, есть две независимые друг от друга копии структуры со ссылками на одни и те же значения.
Ничего по завершению цикла никуда само не применяется, тот массив, по которому бежит foreach, и переменная, доступная по имени $a — это две разные переменные, и первая из них по завершению цикла просто выбрасывается.
Ссылку можете добавить, но и по тем ссылкам, что уже приведены, написано примерно то же самое :)
Ничего по завершению цикла никуда само не применяется, тот массив, по которому бежит foreach, и переменная, доступная по имени $a — это две разные переменные, и первая из них по завершению цикла просто выбрасывается.
Ссылку можете добавить, но и по тем ссылкам, что уже приведены, написано примерно то же самое :)
Следить за памятью нужно при использовании расширений — PDFLib может запросто отожрать гигабайт.
Скорее всего потерянные 88 байт – это ещё одна «магическая» оптимизация php.
При создании объекта, если в нём не было изменений («объект не понадобился») он затем используется, при создания объекта повторно. Звучит запутано, но вот пример:
Тоже самое без unset вернёт разные хеши объектов.
При этом если использовать какой-то класс имеющий конструктор – объект не будет создан повторно (в хе таблице), но будет вызван повторно конструктор.
Это будет иметь высасаный из пальца сайд эффект в случае если вам зачем-то нужно хеши созданных объектов где-нибудь хранить (зачем я не смог придумать):
При создании объекта, если в нём не было изменений («объект не понадобился») он затем используется, при создания объекта повторно. Звучит запутано, но вот пример:
$a = new stdClass();
echo spl_object_hash($a); //000000007843f529000000002ad1ffeb
unset($a);
echo spl_object_hash(new stdClass()); //000000007843f529000000002ad1ffeb
Тоже самое без unset вернёт разные хеши объектов.
При этом если использовать какой-то класс имеющий конструктор – объект не будет создан повторно (в хе таблице), но будет вызван повторно конструктор.
Это будет иметь высасаный из пальца сайд эффект в случае если вам зачем-то нужно хеши созданных объектов где-нибудь хранить (зачем я не смог придумать):
<?php
class A {
public function __construct() {
echo ' [construct] ';
AllA::addHash(spl_object_hash($this));
}
}
class AllA {
static protected $_hashes = array();
static public function addHash($hash) {
self::$_hashes[] = $hash;
}
static public function getHashes() {
return self::$_hashes;
}
}
echo 'new A: '; $a = new A();
echo 'a hash: ', spl_object_hash($a), PHP_EOL; //new A: [construct] a hash: 000000001b77b1850000000057548e86
echo 'unset a', PHP_EOL;
unset($a);
echo 'object with no referance hash: ',
spl_object_hash(new A()), PHP_EOL;
//object with no referance hash: [construct] 000000001b77b1850000000057548e86
echo 'All hashes:', PHP_EOL, join(PHP_EOL, AllA::getHashes());
//здесь будут два одинаковых значения 000000001b77b1850000000057548e86
Уточню, что созданный «чистый» объект будет жить до конца выполнения скрипта и будет всегда использоваться для создания новых объектов. Однако при хотябы каком-нибудь изменении будет создаваться копия, куда уже эти изменения и попадут.
P.S Что-то по воскресеньям не могу излагать мысли в простом виде: )
P.S Что-то по воскресеньям не могу излагать мысли в простом виде: )
Боюсь, что spl_object_hash возвращает просто хэш от идентификатора объекта, который можно посмотреть var_dump.
Разница в идентификаторах и хэшах выделена "*".
class asf{
public $asf = 1;
}
$a = new asf();
var_dump($a);
echo spl_object_hash($a).PHP_EOL; //00000000702b718*8*000000003d3a961b
var_dump($a); //object(asf)#*1* (1) {["asf"]=>int(1)}
unset($a);
$b = new stdClass();
echo spl_object_hash($b).PHP_EOL; //00000000702b718*8*000000003d3a961b
var_dump($b); //object(stdClass)#*1* (0) {}
$c = new asf();
echo spl_object_hash(new asf()).PHP_EOL; //00000000702b718*a*000000003d3a961b
var_dump($c); //object(asf)#*2* (1) {["asf"]=>int(1)}
Разница в идентификаторах и хэшах выделена "*".
Именно так он и поступает :) За подробностями можно заглянуть в ext/spl/php_spl.c (и поискать php_spl_object_hash), причём базовый хеш намерено рандомизируется в кажом вызове.
Я таким образом хотел проиллюстрировать, что это один и тот же объект. Можно это понять и через var_dump, но как-то менее наглядно, плюс мне нужно было значение в виде переменной.
Я таким образом хотел проиллюстрировать, что это один и тот же объект. Можно это понять и через var_dump, но как-то менее наглядно, плюс мне нужно было значение в виде переменной.
Дык, ни о каком прототипировании речи быть не может. Посмотрите в моём коде разные объекты разных классов имеют одинаковый id и одинаковый хэш, а объекты одного и того же класса имеют разные id и разные хэши.
Или вот такой пример, который показывает, что id объекта не всегда увеличивается, в качестве id берётся первое свободное значение начиная с 1.
class Foo{
protected $_test = 100;
}
$foo1 = new Foo();
$foo2 = new Foo();
$foo3 = new Foo();
echo spl_object_hash($foo1).PHP_EOL; //000000005e3115f60000000047e5edc1
var_dump($foo1); // object(Foo)#1 (1) {["_test":protected]=>int(100)}
echo spl_object_hash($foo2).PHP_EOL; //000000005e3115f50000000047e5edc1
var_dump($foo2); // object(Foo)#2 (1) {["_test":protected]=>int(100)}
echo spl_object_hash($foo3).PHP_EOL; //000000005e3115f40000000047e5edc1
var_dump($foo3); //object(Foo)#3 (1) {["_test":protected]=>int(100)}
$foo1 = new stdClass();
echo spl_object_hash($foo1).PHP_EOL; //000000005e3115f30000000047e5edc1
var_dump($foo1); //object(stdClass)#4 (0) {}
$foo1 = new stdClass();
echo spl_object_hash($foo1).PHP_EOL; //000000005e3115f60000000047e5edc1
var_dump($foo1); //object(stdClass)#1 (0) {}
Или вот такой пример, который показывает, что id объекта не всегда увеличивается, в качестве id берётся первое свободное значение начиная с 1.
Странные эти 88 байт.
P.S. То, что выводит скрипт пишите сразу в коде в конце строки — так смотреть гораздо удобнее и статья получается короче.
memoryUsage(memory_get_usage(), $base_memory_usage);//Bytes diff: 0
memoryUsage(memory_get_usage(), $base_memory_usage);//Bytes diff: 88
P.S. То, что выводит скрипт пишите сразу в коде в конце строки — так смотреть гораздо удобнее и статья получается короче.
Спасибо, давненько ничего такого полезного не было!
> Но сразу после цикла, потребление памяти вернулось к прежнему значению
Каждый foreach делает копию массива
Каждый foreach делает копию массива
А меня вот еще какой вопрос мучит:
PHP интерпретатор. Значит он в процессе выполнения где-то имена переменных хранит. Конечно эта память после освобождается, но пока скрипт отсчитывается — где-то все хранится. А раз хранится, то длинна значения переменных что-то значит. Код с использованием переменной iNomberOfMonkeysOnThePalmThee будет больше кушать чем с переменной iMonkey///Возможно это копейки, но тем не менее.
Возможно я чайник-кофейник и глобально ошибаюсь. Просто у меня большой опыт на С++, а все мои потуги с PHP выполняются где-то на дальных серверах и как их померить вообще загадка. Это вам не ЦЦ-профайлер, где можно было по байтам код расковыривать…
PHP интерпретатор. Значит он в процессе выполнения где-то имена переменных хранит. Конечно эта память после освобождается, но пока скрипт отсчитывается — где-то все хранится. А раз хранится, то длинна значения переменных что-то значит. Код с использованием переменной iNomberOfMonkeysOnThePalmThee будет больше кушать чем с переменной iMonkey///Возможно это копейки, но тем не менее.
Возможно я чайник-кофейник и глобально ошибаюсь. Просто у меня большой опыт на С++, а все мои потуги с PHP выполняются где-то на дальных серверах и как их померить вообще загадка. Это вам не ЦЦ-профайлер, где можно было по байтам код расковыривать…
Длина переменных в PHP не является как таковой проблемой, потому как еще на стадии OpCoda происходит определенная оптимизация. Это можно видеть по например такому опкоду ( www.heypasteit.com/clip/05DW ):
Так что имена переменных конечно хранятся, но жертвовать их длиной в ущерб читаемости — это «экономия на спичках».
compiled vars: !0 = $a // тут в !0 используется как идентификатор для переменной с именем $a
// и дальше работа уже непосредственно с этим идентификатором
INIT_ARRAY ~0 // Создаем массив ~0
ASSIGN !0, ~0 // Присваиваем $a созданный массив
Так что имена переменных конечно хранятся, но жертвовать их длиной в ущерб читаемости — это «экономия на спичках».
Познавательно, спасибо за статью!
Было бы очень мега-круто для полной картины воспользоваться debug версией php и продебажить выполнение. Так как всё описанное лишь косвенное, хотя и показательно.
ПС. Я б и сам сделал, но работы много сильно. Может через пол годика по тестирую, эту особенность надо запомнить.
ПС. Я б и сам сделал, но работы много сильно. Может через пол годика по тестирую, эту особенность надо запомнить.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с памятью (и всё же она есть)