Скорей всего дело во внутреннем устройстве самого интерпретатора. Что в разных ситуациях могут быть различные результаты — при константных строках быстрее конкатенация, при переменных — множественные параметры.
Про конкатенацию я акцентрировал внимание на читабельность. Даже по тесту phpbench.com/ разница производительности ~1.5 — 2 раза. Время затрачиваемое на это операции, очень мало по сравнению с затратами времени на остальные операции. На этом экономить нет смысла.
Быть может и есть какие то совсем специфические приложения, где эта разница может сыграть существенную роль, но я таких не встречал.
>>ага особенно прикольно когда цикл по SQL выборке идет и внутри каждой итерации query('SELECT count(*)...')
Ага, я имел ввиду как раз подобные трудозатратные функции.
Но того на практике не приходилось встречать.
Да, когда понимаешь хорошо сам процесс, то уже не делаешь подобных ошибок. Вообще для чистоты программирования лучше не использовать свои собственные функции в циклах for для ограничения числа итераций. Иначе изменение кода такой функции может повлечь непредсказуемые последствия.
Мобильный веб сам по себе дает удобные возможности. Чем мне импонирует iphone, так это надежностью, и удобством работы в internet. А операторы сотовой связи поощряют использвание мобильных ресурсов, и активно продвигают iphone. Но я не буду утверждать как может изменится ситуация с развитием сетей 4G + с выходом android.
Да, статистика поражает… Но например билайн имеет сайт, сделанный специально под iphone. i.beeline.ru/. Сделанный в стиле интерфейса iphone. И там есть сервис нахождения ближайшей к вам точки доступа Beeline Wi-Fi. Если билайн инвестирует в это деньги, значит это скорей всего окупается.
да, причем можно указать по очереди несколько callback'ов, вызвал spl_autoload_register несколько раз и они будут отрабатываться в указанном порядке.
т.е.
spl_autoload_register('func1');
spl_autoload_register('func2);
Вообще библиотека SPL содержит много полезной.
Я не думаю о таких вещах:) Просто решил, что написать это будет интересно :)
Процесс происходил примерно так: на прошлой недели я парсил англоязычные ресурсы по веб разработке, и наткнулся на эту статью. Мне она показалась местами интересной,, но в тоже время сразу появилось много мыслей, протестующих против такой оптимизацией, и также мысли взвешивающие ее смысл. И решил изложить эти мысли. Что имеет смысл оптимизировать, что нет, и когда. И каким образом.
Сам я не занимаюсь оптимизацией до того момента пока проект не запущен.
Больше всего внимание уделяю архитектуре(иногда до фанатизма, и забываю о любой оптимизации:) ), удобству использования API, периодически вспоминаю принципы agile dev, и чтобы все строилось на шаблонах :) Уделяю много внимания читаемости кода, и документированию проекта.
Да, я знаю:) Хотя бы потому что имел опыт работы с людьми, кто был помешан на такой оптимизации, и достаточно намучался. Но я решил дать критику каждому совету в этой статье на основе своего опыта разработки. И добавил вначале что не призываю ими пользоваться, а рассмотриваюсмысл каждого в отдельности.
Конечно, хотелось все написать в один пост, но получилось бы слишком много, да и не находится сразу такого количества времени. А просто перевод делать не хотел, потому что с одной стороны статья показалась интересной, с другой стороны во многом с ней не согласен. И поэтому наоборот в своих комментариях к ней не призываю делать как там написано, а задуматься о осмысленности сих действий, основываясь на своих знаниях и опыте. Плюс постараюсь добавить любую конструктивную критику в пост.
Я видел print в проектах, но редко. Мне он не мешает, поэтому я не писал четких указаний использовать то или то, а просто привел описание echo и print и обосновал почему print работает немного медленней. Это дело привычки, и само собой экономить на этом и переходить на echo, если вы всю жизнь использовали print нет смысла, и не призываю к этому :)
Про итерации я и написал, что прирост можно ощутить только на большом количестве итераций. Я старался сильно отталкиваться от опыта разработки, и что перевешивает в данном случае важнее — удобство, читабельность, подддержка кода или оптимизация. Там приведены тесты, и само собой на большом количестве итераций.
Я сам часто использую подсчет количества итераций в самом цикле:) Но если бы вместо подсчета размера массива ограничителем числа итераций стояла самописная трудозатратная функция, я бы либо оптимизировал саму функцию. либо ее результат посчитал заранее. :)
Поэтому я решил делать не просто перевод, а постарался рассмотреть смысл такой оптимизации. Ставя на первое место качество кода, удобство разработки и поддержки + постарался найти случаи, когда такая оптимизация может иметь смысл. И как говорят отцы программирования, делать это только после написания кода.
И конечно рад любой конструктивной критики. Для этого и писал. Все интересно в комментариях добавлю в статью, с указанием автора.
>А не выбрасывается ли результат с помощью echo, и использовать его советуют, потому что echo является функцией, как тот же printf, а относится к «конструкции языка»
Да, является конструкцией языка, оговорился, но в то же время в документации описывается и как функция.
Как я помню echo работает быстрее из-за того что в отличие от print не возвращает значения.
Известный факт, тестов не найду сейчас, что переменные вставленные в строку работают быстрее чем конкатенация.
Парсят. Выделяют переменные, классы, методы функции в отдельном окошке тагов, если его открывать. Я не ковырялся особо, может быть и можно их настроить хорошо. Но в стандартной настройки они работают просто как словарь.
Быть может и есть какие то совсем специфические приложения, где эта разница может сыграть существенную роль, но я таких не встречал.
Ага, я имел ввиду как раз подобные трудозатратные функции.
Но того на практике не приходилось встречать.
Да, когда понимаешь хорошо сам процесс, то уже не делаешь подобных ошибок. Вообще для чистоты программирования лучше не использовать свои собственные функции в циклах for для ограничения числа итераций. Иначе изменение кода такой функции может повлечь непредсказуемые последствия.
т.е.
spl_autoload_register('func1');
spl_autoload_register('func2);
Вообще библиотека SPL содержит много полезной.
Процесс происходил примерно так: на прошлой недели я парсил англоязычные ресурсы по веб разработке, и наткнулся на эту статью. Мне она показалась местами интересной,, но в тоже время сразу появилось много мыслей, протестующих против такой оптимизацией, и также мысли взвешивающие ее смысл. И решил изложить эти мысли. Что имеет смысл оптимизировать, что нет, и когда. И каким образом.
Сам я не занимаюсь оптимизацией до того момента пока проект не запущен.
Больше всего внимание уделяю архитектуре(иногда до фанатизма, и забываю о любой оптимизации:) ), удобству использования API, периодически вспоминаю принципы agile dev, и чтобы все строилось на шаблонах :) Уделяю много внимания читаемости кода, и документированию проекта.
>> 8. По возможности используйте require() вместо require_once(). [статья]
>Может быть вы наоборот хотели написать?
Это перевод 8го пункта оригинала статьи. Ниже курсивом мой текст в опровержение этого.
Конечно, хотелось все написать в один пост, но получилось бы слишком много, да и не находится сразу такого количества времени. А просто перевод делать не хотел, потому что с одной стороны статья показалась интересной, с другой стороны во многом с ней не согласен. И поэтому наоборот в своих комментариях к ней не призываю делать как там написано, а задуматься о осмысленности сих действий, основываясь на своих знаниях и опыте. Плюс постараюсь добавить любую конструктивную критику в пост.
Про итерации я и написал, что прирост можно ощутить только на большом количестве итераций. Я старался сильно отталкиваться от опыта разработки, и что перевешивает в данном случае важнее — удобство, читабельность, подддержка кода или оптимизация. Там приведены тесты, и само собой на большом количестве итераций.
Я сам часто использую подсчет количества итераций в самом цикле:) Но если бы вместо подсчета размера массива ограничителем числа итераций стояла самописная трудозатратная функция, я бы либо оптимизировал саму функцию. либо ее результат посчитал заранее. :)
И конечно рад любой конструктивной критики. Для этого и писал. Все интересно в комментариях добавлю в статью, с указанием автора.
Да, является конструкцией языка, оговорился, но в то же время в документации описывается и как функция.
Как я помню echo работает быстрее из-за того что в отличие от print не возвращает значения.
Известный факт, тестов не найду сейчас, что переменные вставленные в строку работают быстрее чем конкатенация.
www.flickr.com/photos/30496122@N07/2862367534/sizes/o/