Comments 105
В избранное. Читать последнее предложение как мантру.
Знаешь... Оптимизация - это то, что пришло к нам со времен С(++). Сейчас железо стоит дешевле человеко-часов (взять во внимание человек-часы).
Была бы возможность плюсануть, но это не к отрийательной карме... Хватит заморачиваться на мелочах - начните смотреть на проблему в целом, если быстрее и выгоднее кэшить - кэшируйрте, если нужно оптимайзить, пересмотрите алгоритм! сравнивать принт и эхо - это маразм!
Была бы возможность плюсануть, но это не к отрийательной карме... Хватит заморачиваться на мелочах - начните смотреть на проблему в целом, если быстрее и выгоднее кэшить - кэшируйрте, если нужно оптимайзить, пересмотрите алгоритм! сравнивать принт и эхо - это маразм!
Сегодня вроде бы не 1 апреля. Сразу вспомнил о http://habrahabr.ru/blog/php/39115.html
Если вы пишите на PHP, забудьте про микрооптимизацию. Продуманное кеширование в 1000 раз эффективнее. А то получается экономия на спичках.
А то замучали бедный PHP. Уже и скорость обработки разных строк ('' vs. "") мерили, и скорость обработки констант со скоростью обработки переменных сравнивали, теперь вот print с echo сравниваем. Даёшь 3 мс выигрыша на каждую страницу!
А то замучали бедный PHP. Уже и скорость обработки разных строк ('' vs. "") мерили, и скорость обработки констант со скоростью обработки переменных сравнивали, теперь вот print с echo сравниваем. Даёшь 3 мс выигрыша на каждую страницу!
Но все-таки лучше использовать echo. Не люблю print)
UFO just landed and posted this here
Чем бы 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 раза, и любые рассуждения затмит только тот факт, что р а з н и ц а - е с т ь! А дальше - "в масштабах интернета"!
Дело не в том, как я понял статью. А в том, как она написана.
просто большой респект!
я за здравый смысл в разработке, а не слепую веру в догмы о производительности...
я за здравый смысл в разработке, а не слепую веру в догмы о производительности...
UFO just landed and posted this here
Отличная статья! Тоже долго думал над этим, но не задумывался столь всеръез как автор.
Вот это называется нормальным решением вопроса. Сел, потестил, озвучил. Уважаю.
Делайте еще 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'. Ибо я привык связывать строки с помощью оператора "точка".
Sign up to leave a comment.
Эхо или печать?