Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 105
В избранное. Читать последнее предложение как мантру.
Знаешь... Оптимизация - это то, что пришло к нам со времен С(++). Сейчас железо стоит дешевле человеко-часов (взять во внимание человек-часы).
Была бы возможность плюсануть, но это не к отрийательной карме... Хватит заморачиваться на мелочах - начните смотреть на проблему в целом, если быстрее и выгоднее кэшить - кэшируйрте, если нужно оптимайзить, пересмотрите алгоритм! сравнивать принт и эхо - это маразм!
Была бы возможность плюсануть, но это не к отрийательной карме... Хватит заморачиваться на мелочах - начните смотреть на проблему в целом, если быстрее и выгоднее кэшить - кэшируйрте, если нужно оптимайзить, пересмотрите алгоритм! сравнивать принт и эхо - это маразм!
Сегодня вроде бы не 1 апреля. Сразу вспомнил о http://habrahabr.ru/blog/php/39115.html
Если вы пишите на PHP, забудьте про микрооптимизацию. Продуманное кеширование в 1000 раз эффективнее. А то получается экономия на спичках.
А то замучали бедный PHP. Уже и скорость обработки разных строк ('' vs. "") мерили, и скорость обработки констант со скоростью обработки переменных сравнивали, теперь вот print с echo сравниваем. Даёшь 3 мс выигрыша на каждую страницу!
А то замучали бедный PHP. Уже и скорость обработки разных строк ('' vs. "") мерили, и скорость обработки констант со скоростью обработки переменных сравнивали, теперь вот print с echo сравниваем. Даёшь 3 мс выигрыша на каждую страницу!
Но все-таки лучше использовать echo. Не люблю print)
Чем бы php-программист не тешился, лишь бы не лез в веб-программирование.
В Вилларибо тестят чо быстрее в пхп: принт или ехо, а в Виллобаджо давно пропивают только что выполненный сайт.
Судорожно начал вспоминать все свои проекты на наличие 'echo' или 'print'... Оказалось везде 'echo'. И всё же даже такой твик будет полезен, Спасибо. Плюсанул карму +1
Вдогонку тоже немного поэкспериментировал, слегка изменив первоначальыне условия - 1000 раз выводим случайно сгенеренные строки (шафл по комбинации крипта и md5 от пяти произвольных непустых символов с сайта http://www.rbc.ru) длиной больше 32 Кб каждая, используем три варианта print (соответствуют первому и третьему, а еще вызов print как функции) и echo с одинарными кавычками.
Получается следующая картинка - c eAccelerator среднее время в случае print - 0.93, в случае echo - 0.88, с выключенным eAccelerator - 2.11 и 1.07 соответственно. Внутри отдельных вызово print расброс невелик. Правда, тут возможны паразитарные (для чистоты эксперимента) влияния конфигурации (nginx + apache на разных VDS).
Получается следующая картинка - c eAccelerator среднее время в случае print - 0.93, в случае echo - 0.88, с выключенным eAccelerator - 2.11 и 1.07 соответственно. Внутри отдельных вызово print расброс невелик. Правда, тут возможны паразитарные (для чистоты эксперимента) влияния конфигурации (nginx + apache на разных VDS).
покажите мне хоть один код, где бы использовалось хотябы 1000 эх или принтов.
в итоге вы просто зря потратили своё время
в итоге вы просто зря потратили своё время
Действительно, гулять так гулять — хотелось бы еще увидеть сравнение с
а то мало ли вдруг ;)
<? echo $value ?><br />
и
<?= $value ?><br />
а то мало ли вдруг ;)
Ну ежели интересно, то 1,576 и 1,051 (sic!) соответственно.
Теперь еще интереснее. Особенно, если учитывать, что <?= это якобы то же самое, что и <? echo .
Или в чем-то подвох?
Или в чем-то подвох?
Забавно.
И неожиданно.
И неожиданно.
Спасибо, интересно!
небольшая и хорошая статья.
Не понятно чего добивался автор. Из статьи «40 советов» и так было ясно что это не мануал для оптимизации логики, а мануал для оптимизации кода под машину. И то, лишь «советы». Автор той статьи ни где не говорил что это мега способы для оптимизации, которые снимут с вас нагрузку. Он лишь показывал факты. А вы, автор, лишь подтвердили его словам.
p.s. на работающем проекте частенько проще оптимизировать код, нежели какой-то скуль запрос.
p.s. на работающем проекте частенько проще оптимизировать код, нежели какой-то скуль запрос.
ппц .
Часы легче искать не там, где потерял, а под фонарем — под ним светлее.
Часы легче искать не там, где потерял, а под фонарем — под ним светлее.
во во. вместо того, чтобы достать телефон и посветить себе, вы пойдете к ближайшему фонарю?
Ты всегда такой удак, или специально для меня стараешься?
Я не обсуждаю сейчас идиотское утверждение, будто на работающем проекте сложнее отладить запрос, чем колупаться с кавычечьками. Видимо, выполнить EXPLAIN в консоли — неразрешимая задача для быдлокодера.
Но вот заявка о том, что кавычечки оптимизировать проще — это ппц. Раз проще, то и будем оптимизировать.
Я не обсуждаю сейчас идиотское утверждение, будто на работающем проекте сложнее отладить запрос, чем колупаться с кавычечьками. Видимо, выполнить EXPLAIN в консоли — неразрешимая задача для быдлокодера.
Но вот заявка о том, что кавычечки оптимизировать проще — это ппц. Раз проще, то и будем оптимизировать.
Скажи, а что ты можешь кроме как материться и кешировать? Быдлокодеры не умеют писать explain? Возможно. Так же быдлокодеры матеряться и ищут решение проблем в кешировании, акселерации итп.
Представь себе большой проект, при проектировании которого были учтены все мелчайшие детали. Хранилища выбраны, индексы расставлены относительно будующих запросов, поставлен акселератор и настроен мемкеш. Представь что этот проект посещают миллионы в день. Представь, что оптимизация тебе и не нужна вовсе, у тебя куча back-front серверов и растить их есть куда, у тебя тебя отдельный массив под master-slave серваки мускуля и достаточно тачек под мемкеш. Представь, что оптимизируя код ты ощущаешь совсем маленький прирост производительности, который повлек за собой большую пропускную способность и количество просмотров страниц.
И что ты пристал к кавычкам? Больная тема? Тебя в детстве заставляли использовать одинарные кавычки?? Говоря о оптимизации кода я имел введу прописывание полных путей, оптимизация php.ini итп. Все, что не относится к исправлению логики.
Представь себе большой проект, при проектировании которого были учтены все мелчайшие детали. Хранилища выбраны, индексы расставлены относительно будующих запросов, поставлен акселератор и настроен мемкеш. Представь что этот проект посещают миллионы в день. Представь, что оптимизация тебе и не нужна вовсе, у тебя куча back-front серверов и растить их есть куда, у тебя тебя отдельный массив под master-slave серваки мускуля и достаточно тачек под мемкеш. Представь, что оптимизируя код ты ощущаешь совсем маленький прирост производительности, который повлек за собой большую пропускную способность и количество просмотров страниц.
И что ты пристал к кавычкам? Больная тема? Тебя в детстве заставляли использовать одинарные кавычки?? Говоря о оптимизации кода я имел введу прописывание полных путей, оптимизация php.ini итп. Все, что не относится к исправлению логики.
Использую print по аналогии с Perl и коментарии ввиде # - так глазу приятней.
Статья познавательно тем, что так и буду использовать print раз "406 наносекунд на одну операцию".
Статья познавательно тем, что так и буду использовать print раз "406 наносекунд на одну операцию".
Основной плюс echo перед print, это то что нужно нажимать на одну клавишу меньше :)
предпочитаю писать echo лишь из-за того, что когда-то прочитал подобное, да и буков 4 против 5 - набирать не сложно, но зрительно заметно.
Но например, работая с друпал - пишу print, дабы не нарушать стиль его кода, в котором echo не встретишь.
2 Автор: может теперь еще и тест про одинарные кавычки + конкатенация vs двойные ;)
Но например, работая с друпал - пишу print, дабы не нарушать стиль его кода, в котором echo не встретишь.
2 Автор: может теперь еще и тест про одинарные кавычки + конкатенация vs двойные ;)
echo - 4 символа, print - 5 символов. Итого, echo быстрее набирается руками, чем print в 1,25 раза :0)
Буквы p,r,i,n,t - разбросаны по клаве. Каждая последующая буква набирается пальцем _другой_ руки. Поясняю принцип: пока набиваешь одну букву, второй рукой позиционируешь на следующую букву. А первые две буквы в "echo" сидят на клавиатуре совсем рядышком. Вторая рука в момент набора первых двух букв банально простаивает(!). Теряем драгоценные секунды времени ни на что! Потом последние буквы тоже набираем одноруким методом. Так что эффект скорости набора будет обратный: print будет набираться быстрее, чем echo.
Это сравнение может и интересно, но на практике бесполезно. Автор не уточнил, какое у него железо. И забыл оценить железо на серверах "Вконтакта". Разница в скорости выполнения может достигать 1-2 порядков, а в этом случае припрост даже 0,023% на столько смешен, что прочтение статьи, а тем более ее написание — зря потраченное время.
Я писал print, пишу print и буду писать print (правда один раз на запрос). А если вы собираетесь гоняться за микросекундами, пишите на C.
Я писал print, пишу print и буду писать print (правда один раз на запрос). А если вы собираетесь гоняться за микросекундами, пишите на C.
В общем ещё можно задуматься про причины наличия разницы, в мануале чётко сказано про то, что echo результат не возвращает, а print возвращает 1, т.е. print = echo + операция по сохранению результата во временную переменную. Это по определению медленее, но не настолько, чтобы обращать на это внимание :).
Более интересна ситуация с echo $a, $b, $c; VS echo $a . $b . $c. А ещё более интересна ситуация с накоплением вывода в $out путём сотни-другой конкатенаций, а потом вывода. Вот здесь разница будет ощутимой.
Дело в том, что echo $a, $b = поместить в буффер вывода сначала $a, потом $b. Теперь учтём, что буффер для этого предназначен, т.е. в нём память выделяется с запасом, это даст то, что такая операция скорее всего не будет приводить к выделению памяти (вернее будет, но редко, когда буффер переполняется и нужен новый большой кусок памяти).
А вот echo $a . $b = провести конкатенацию строк $a, $b (выделить память, скопировать), потом положить в буффер вывода (который также придётся изменять, если он переполнится, или не придётся, если его хватит). Таким образом имеем всегда дополнительное выделение памяти и дополнительное лишнее копирование.
С конкатенацией ещё забавнее - вариант $out .= $a, и т.п., каждая такая операция - это перевыделение памяти, причём под конец накопления страницы достаточно большого объёма. Это объясняется тем, что в zval'е хранится только указатель на строку + длина, т.е. память выделяется ровно на строку. Вообще в PHP довольно хитрый менеджер памяти (сейчас попробовал вчитаться в исходники, что там). Там для этого случая идёт свой realloc, а он как повезёт, либо просто задействует новый кусок памяти за переменной (если он есть), либо, если его нет - выделяет новый большой и копирует туда.
Подводя итог:
ob_start();
// много раз echo
$result = ob_get_clean();
на большом количестве echo быстрее, чем накопление в $result.
А вот обращать на это внимание или нет - дело каждого. Я просто включил все эти мелочи в свой стиль, т.е. пишу так весь код, приятно знать, что он будет изначально работать чуть быстрее. Хотя вылизыванием старого кода так заниматься не стоит - есть куда более действенные способы оптимизации. А так - если есть два варианта сделать одно и то же, и они одинаковы по сложности реализации, то почему не выбрать тот, что работает быстрее? :)
Более интересна ситуация с echo $a, $b, $c; VS echo $a . $b . $c. А ещё более интересна ситуация с накоплением вывода в $out путём сотни-другой конкатенаций, а потом вывода. Вот здесь разница будет ощутимой.
Дело в том, что echo $a, $b = поместить в буффер вывода сначала $a, потом $b. Теперь учтём, что буффер для этого предназначен, т.е. в нём память выделяется с запасом, это даст то, что такая операция скорее всего не будет приводить к выделению памяти (вернее будет, но редко, когда буффер переполняется и нужен новый большой кусок памяти).
А вот echo $a . $b = провести конкатенацию строк $a, $b (выделить память, скопировать), потом положить в буффер вывода (который также придётся изменять, если он переполнится, или не придётся, если его хватит). Таким образом имеем всегда дополнительное выделение памяти и дополнительное лишнее копирование.
С конкатенацией ещё забавнее - вариант $out .= $a, и т.п., каждая такая операция - это перевыделение памяти, причём под конец накопления страницы достаточно большого объёма. Это объясняется тем, что в zval'е хранится только указатель на строку + длина, т.е. память выделяется ровно на строку. Вообще в PHP довольно хитрый менеджер памяти (сейчас попробовал вчитаться в исходники, что там). Там для этого случая идёт свой realloc, а он как повезёт, либо просто задействует новый кусок памяти за переменной (если он есть), либо, если его нет - выделяет новый большой и копирует туда.
Подводя итог:
ob_start();
// много раз echo
$result = ob_get_clean();
на большом количестве echo быстрее, чем накопление в $result.
А вот обращать на это внимание или нет - дело каждого. Я просто включил все эти мелочи в свой стиль, т.е. пишу так весь код, приятно знать, что он будет изначально работать чуть быстрее. Хотя вылизыванием старого кода так заниматься не стоит - есть куда более действенные способы оптимизации. А так - если есть два варианта сделать одно и то же, и они одинаковы по сложности реализации, то почему не выбрать тот, что работает быстрее? :)
Очень интересное приложение к основному топику, спасибо!
Про то, что при последовательном сложении множества строк, быстрее загнать их (указатели на них) в массив, а в конце одним махом выделить память и по одному разу скопировать, мысль в принципе правильная.
И во многих языках подобные действия могут повышать эффективность на порядки.
Однако, PHP, это в своей основе язык обработки текста и что-что, а подобные операции там реализованы достаточно здорово. Так что подобная оптимизация в неё не всегда даёт существенный эффект.
И во многих языках подобные действия могут повышать эффективность на порядки.
Однако, PHP, это в своей основе язык обработки текста и что-что, а подобные операции там реализованы достаточно здорово. Так что подобная оптимизация в неё не всегда даёт существенный эффект.
Я здесь никак не трогаю массивы :), речь идёт о буфере вывода, это несколько другое, это можно понимать как массив конечно, но в терминах Си, т.е. некоторая область памяти. По поводу "оптимизации под обработку текста" - никто не спорит, просто я рассмотрел то, что делает PHP "за сценой", причём не предполагая что-то, а почитав исходники PHP :), это ли не первоисточник, чтобы понять суть?
По оптимизации там кстати много сделано, но скорее в области выделения памяти, в том числе небольших блоков (это обсулавливает ускорение пхп 5.2 по сравнению с предыдущими версиями), суть операции конкатенации от этого не меняется.
Ну и ещё раз, это микрооптимизация, этим можно не заниматься и жить нормально, это так, "хозяйке на заметку" :).
По оптимизации там кстати много сделано, но скорее в области выделения памяти, в том числе небольших блоков (это обсулавливает ускорение пхп 5.2 по сравнению с предыдущими версиями), суть операции конкатенации от этого не меняется.
Ну и ещё раз, это микрооптимизация, этим можно не заниматься и жить нормально, это так, "хозяйке на заметку" :).
Окей, теперь мы знаем, какая конструкция быстрее. Почему бы ее и не применять?
echo - есть одоименная команда в bash.
А меня всегда мучал вопрос кто и где использует echo и print?
А меня всегда мучал вопрос кто и где использует echo и print?
Хотите оптимизировать — посмотрите, как в языке реализованы print и echo. При такой незначительной разнице по времени ничего сказать об эффективности нельзя, и уж тем более в корне неверно экстраполировать эти измерения в духе «а за год накопится два часа серверного времени».
Автор, браво за финал. Так их!
вы предлагаете не тратить время на исследование производительности, когда уже знаете заранее о том, что прироста не будет
но ведь это не во всех случаях так. часто, как говорится, лучше день потерять - потом за пять минут долететь
но ведь это не во всех случаях так. часто, как говорится, лучше день потерять - потом за пять минут долететь
Когда это я такое предлагал? :)
В принцуипе, замечание верное.
Именно поэтому автору не помешает добавить в статью резюме о том, что поводом для любых замеров должен служить п р о ф а й л и н г.
Именно поэтому автору не помешает добавить в статью резюме о том, что поводом для любых замеров должен служить п р о ф а й л и н г.
Отличное исследование. Хотя в принципе я уже знал правильный ответ. Еще давным давно прочитал его в "Professional PHP Programming".
Все бы ничего, но аффтар не учитывает одну важную вещь.
Настолько важную, что ценность всех этих говнотестов - гораздо меньше 0,0023%
Распорстраненная практика "мильён итераций бессмысленного кода" измеряет сферического хомячка в вакууме.
Сделай кусок реалного кода, который, пусть даже не получает данные, а просто их обрабатывает минимально перед выводом. И позапускай тесты с ним.
И вся разница волшебным образом растворится.
При этом мы не учитываем, что тот самый сайт с мильёном хитов исполняется не в режиме "скрипт один раз запустили, и у него внутре все крутится". Нет. На каждый из этих хитов поднимается вею-сервер (это мы не меряем), парсится, по буковке, наш скрипт (этап убирается акселератором), и только после этого мы приступаем к выполнению нашего драгоценного echo.
При этом совершаются десятки файловых операций ввода-вывода, которые в сотни раз тормознее разницы эхо и принт.
то есть, в реальности нету даже этого рироста в 0,23%.
то есть, дело не в том, мал или велик прирост.
дело в том, что его вообще н е т.
Настолько важную, что ценность всех этих говнотестов - гораздо меньше 0,0023%
Распорстраненная практика "мильён итераций бессмысленного кода" измеряет сферического хомячка в вакууме.
Сделай кусок реалного кода, который, пусть даже не получает данные, а просто их обрабатывает минимально перед выводом. И позапускай тесты с ним.
И вся разница волшебным образом растворится.
При этом мы не учитываем, что тот самый сайт с мильёном хитов исполняется не в режиме "скрипт один раз запустили, и у него внутре все крутится". Нет. На каждый из этих хитов поднимается вею-сервер (это мы не меряем), парсится, по буковке, наш скрипт (этап убирается акселератором), и только после этого мы приступаем к выполнению нашего драгоценного echo.
При этом совершаются десятки файловых операций ввода-вывода, которые в сотни раз тормознее разницы эхо и принт.
то есть, в реальности нету даже этого рироста в 0,23%.
то есть, дело не в том, мал или велик прирост.
дело в том, что его вообще н е т.
Я измеряю время работы только операций вывода, и говорю только о нём.
А хрен ли о нем говорить?
Обсуждая проблему, ты подтверждаешь её наличие.
Когда на самом длее её нет.
Вывод твоего исследования - что разница е с т ь.
В этом содержится две проблемы.
Во-первых, здесь полно идиотов, которые не понимают, что разница мизерная. Зато теперь они запомнили, что "эхо быстрее".
Во-вторых на самом деле разницы нет. Никакой.
И статья, которая показывала бы именно это - была бы в сто раз ценнее.
Обсуждая проблему, ты подтверждаешь её наличие.
Когда на самом длее её нет.
Вывод твоего исследования - что разница е с т ь.
В этом содержится две проблемы.
Во-первых, здесь полно идиотов, которые не понимают, что разница мизерная. Зато теперь они запомнили, что "эхо быстрее".
Во-вторых на самом деле разницы нет. Никакой.
И статья, которая показывала бы именно это - была бы в сто раз ценнее.
Ну и мудак.
Что я еще могу сказать.
Что я еще могу сказать.
Ну, например: спасибо за поднятую карму.
Спасибо.
Занятие столь же бесполезное, сколь и измерение разницы между эхо и принт.
Я не резидент хабра. Захожу исключительно по ссылкам.
И считаю, что по-настоящему свободен только тот, у кого отрицательная карма. можно считать это протестом против системы поощрения посредственностей посредственностями, принятой на этом сайте.
Так что можно было потратить и с большей пользой.
Ну неужели непонятно, что Бородин тоже может сказать, что "я не имел в виду реальную производительность!". Не имел. Но его статью уже 7 лет ламеры приводят друг другу в пример.
Тут даже в каментах, имея перед глазами оригинальный текст, контекст, и обсуждение - и то умудряются понять неправильно. А что будет, когда растащат - вообще туши свет. Человек так устроен, он слышит только то, что хочет услышать. Поэтому о,2 процента превратится в о,2 раза, и любые рассуждения затмит только тот факт, что р а з н и ц а - е с т ь! А дальше - "в масштабах интернета"!
Дело не в том, как я понял статью. А в том, как она написана.
Занятие столь же бесполезное, сколь и измерение разницы между эхо и принт.
Я не резидент хабра. Захожу исключительно по ссылкам.
И считаю, что по-настоящему свободен только тот, у кого отрицательная карма. можно считать это протестом против системы поощрения посредственностей посредственностями, принятой на этом сайте.
Так что можно было потратить и с большей пользой.
Ну неужели непонятно, что Бородин тоже может сказать, что "я не имел в виду реальную производительность!". Не имел. Но его статью уже 7 лет ламеры приводят друг другу в пример.
Тут даже в каментах, имея перед глазами оригинальный текст, контекст, и обсуждение - и то умудряются понять неправильно. А что будет, когда растащат - вообще туши свет. Человек так устроен, он слышит только то, что хочет услышать. Поэтому о,2 процента превратится в о,2 раза, и любые рассуждения затмит только тот факт, что р а з н и ц а - е с т ь! А дальше - "в масштабах интернета"!
Дело не в том, как я понял статью. А в том, как она написана.
просто большой респект!
я за здравый смысл в разработке, а не слепую веру в догмы о производительности...
я за здравый смысл в разработке, а не слепую веру в догмы о производительности...
Отличная статья! Тоже долго думал над этим, но не задумывался столь всеръез как автор.
Вот это называется нормальным решением вопроса. Сел, потестил, озвучил. Уважаю.
Делайте еще flush() после операции вывода - будет еще быстрее)
Я некоторое время назад делал такой тест echo и print.
Вот мои результаты.
1) Вариант
for ($i=0; $i < 10000000; $i++) {
echo "";
}
2) Вариант
for ($i=0; $i < 10000000; $i++) {
print "";
}
Каждый вариант испытывался по 12 раз, т.е. каждая операция была произведена 120 000 000 раз:
echo [сек.]--------------- print [сек.]
5,986281157 ----------- 6,259333134
5,959125042 ----------- 6,290648937
5,92988801 ------------- 6,173727989
5,885861874 ----------- 6,203007936
5,900694132 ----------- 6,194453001
5,950232983 ----------- 6,259453058
6,006173134 ----------- 6,186828852
5,8961339 -------------- 6,137470961
5,970099926 ----------- 6,099076986
5,718567133 ----------- 6,190666914
5,911242008 ----------- 6,172640085
5,843736887 ----------- 6,272330046
Сумма:
echo - 70,95803618 сек.
print - 74,4396379 сек.
Среднее время 10 000 000 операций:
echo - 5,913169682 сек.
print - 6,203303158 сек.
Среднее время 1 операции:
echo - 5,91317E-07 сек.
print - 6,2033E-07 сек.
PS: Проверять на 1000 раз, как сделал автор темы не вижу смысла, т.к. малейшее извенение загрузки ЭВМ может сильно повлиять на результат.
PPS: Не знаю, что автор делал в течении 1ч.5м., но тест занимает 6-8 минут.
Вот мои результаты.
1) Вариант
for ($i=0; $i < 10000000; $i++) {
echo "";
}
2) Вариант
for ($i=0; $i < 10000000; $i++) {
print "";
}
Каждый вариант испытывался по 12 раз, т.е. каждая операция была произведена 120 000 000 раз:
echo [сек.]--------------- print [сек.]
5,986281157 ----------- 6,259333134
5,959125042 ----------- 6,290648937
5,92988801 ------------- 6,173727989
5,885861874 ----------- 6,203007936
5,900694132 ----------- 6,194453001
5,950232983 ----------- 6,259453058
6,006173134 ----------- 6,186828852
5,8961339 -------------- 6,137470961
5,970099926 ----------- 6,099076986
5,718567133 ----------- 6,190666914
5,911242008 ----------- 6,172640085
5,843736887 ----------- 6,272330046
Сумма:
echo - 70,95803618 сек.
print - 74,4396379 сек.
Среднее время 10 000 000 операций:
echo - 5,913169682 сек.
print - 6,203303158 сек.
Среднее время 1 операции:
echo - 5,91317E-07 сек.
print - 6,2033E-07 сек.
PS: Проверять на 1000 раз, как сделал автор темы не вижу смысла, т.к. малейшее извенение загрузки ЭВМ может сильно повлиять на результат.
PPS: Не знаю, что автор делал в течении 1ч.5м., но тест занимает 6-8 минут.
Я всегда стараюсь подходить тщательно.
Например, много времени заняло выяснение того, как меняются результаты замеров в зависимости от включения буферизации вывода, вывода в прокручиваемый див, вывода в консоль, вывода в консоль с перенаправлением в /dev/null, сравнение быстродействия при включенных и выключенных разнообразных параметрах и многое другое.
Например, много времени заняло выяснение того, как меняются результаты замеров в зависимости от включения буферизации вывода, вывода в прокручиваемый див, вывода в консоль, вывода в консоль с перенаправлением в /dev/null, сравнение быстродействия при включенных и выключенных разнообразных параметрах и многое другое.
Народ echo был быстрее print толкьо потому что echo это поточная команда вывода а print это функция вывода и как говорится что быстрее? ))) Да и кавычки тоже влияют т.к. "" в двойных интерпретатор ищет переменные меняя их значениями а в '' одинарных такой проверки и замены не происходит и аля где-же быстрее )))
Да таких нюансов дофига ))) и надо их обсуждать )))
Да таких нюансов дофига ))) и надо их обсуждать )))
Примите к сведению echo непосредсвенно преобразуется в инструкцию ZEND_ECHO Zend Engine
В то время как print по видимому вызывается как С функция через инструкцию ZEND_DO_FCALL "print"
поэтому echo и быстрее))
В то время как print по видимому вызывается как С функция через инструкцию ZEND_DO_FCALL "print"
поэтому echo и быстрее))
Хорошо написаною Мысленно ставлю вам "плюс".
В доке также есть ссылки, где все различия указаны http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40
я всегда использую echo, с самого начала разработки собственной CMS
Если разница в производительности незначительная, нужно использовать то, что удобнее, красивее. Например я никогда не буду писать echo 'str1', 'str2'. Ибо я привык связывать строки с помощью оператора "точка".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эхо или печать?