Несколько других советов для PHP-разработчиков

    Навеяно вот этим.

    Я решил вспомнить некоторые особенности PHP, связанные с производительностью.

    Отмечу, что включил в свой небольшой список лишь то, что обычно вызывает удивление у junior developers, с которыми мне приходилось работать.
    О банальных вещах, вроде «одинарные кавычки вместо двойных», думаю, знают все, поэтому постараюсь кого-нибудь удивить.

    Результаты и выводы, сделаны на основании нескольких версий PHP, который крутятся на знакомых мне серверах, а именно 5.2.6 из Debian Lenny, 5.3.2 из Ubuntu, и 5.2.14 из dotdeb. Возможно, на других платформах, есть отличия.

    • file_get_contents
      Не секрет, что file_get_contents, использует (memory mapping), прирост от которого, особенно заметен на крупных файлах.
      Следствие этого:
      simplexml_load_string( file_get_contents ('file.xml') )
      работает быстрее, чем:
      simplexml_load_file('file.xml')
      Похоже, что подобные simplexml_load_file функции, базируются на обычных fopen/fread, что приводит к разнице в скорости.

      NB: Также неплохо ускоряется DOM->loadFile, и некоторые другие функции с похожим поведением.

      Если вы разбираете файл с \n разделителями (или к примеру CSV, TSV, или нечто подобное), советую заменить file() на
      explode(PHP_EOL, file_get_contents('file.xml'));
      Спасибо за подсказку c PHP_EOL LoneCat
      Прирост будет еще больше, чем в случае с xml.
      Видимо, file() — не очень удачно реализована.
    • count() и sizeof()
      UPD: sizeof() это синоним count(), работает быстрее, спасибо merkushin за поправку.
    • Notices, etc.
      Допускать нотисы, это ужасно, да.
      Но если ваш junior developer, не хочет признавать их важность, расскажите ему, что на генерацию одного notice у PHP уходит время, за которое можно обойти и инкрементировать массив из примерно 30-ти элементов.
    • foreach
      Цикл foreach, практически в каждой статье, посвящённой производительности PHP, предают анафеме.
      На практике, не всё так страшно. Жуткие конструкции, вроде:
      while (list($key, $value) = each($item))
      в реальных условиях, часто бывают медленнее.
      Если же пропустить $key, то эта конструкция проигрывает foreach примерно 30-40%.
    • JSON vs XML
      Скажу лишь, что перейдя на json-файлы для конфигурации, выиграл 20-30% на инициализации ядра. JSON приятен для глаз, иерархичен и быстр.
      Также, json_decode быстрее работает без второго аргумента (генерируя объект, а не массив), но незначительно.
    • mb_ereg vs preg_match
      POSIX — выражения медленные, это опять же, общеизвестно.
      Но движок Oniguruma, который используется в функции mb_ereg, и её mb-собратьях, с этим не согласен, и примерно в двух третях случаев, обгоняет хвалёный preg_match.
    • IGBinary для сериализации.
      Это очень быстрое расширение, с очень компактным значением на выходе.
    • file_exists и include
      Проверять file_exists() затем делать include, дешевле, чем проверять возврат include(), если вы, к примеру, не уверены, что файл на месте.
    • Опять include
      Не знаю почему, но include_once, часто проигрывает по скорости конструкции с принудительной проверкой (записываем в массив все включённые файлы).
    • Static vars
      Статическая переменная класса, самое лучшее место для быстрого получения глобальных данных, замечен прирост в 5 — 10 раз.
    • Напоследок, пара советов
      Показывайте себе время выполнения в миллисекундах, а не в долях секунды.
      Это здорово мотивирует (сравните, «100 миллисекунд» и «0.1 секунды»), и легче читается.
      Очень важно, собирать информацию, не только об абсолютной скорости, но и анализировать вклад отдельных подсистем: ядра, интерфейса данных, рендеринга, и.т.п.
      Свой профайлер, я настроил (на testing-машине) на выброс исключений, при аномальном замедлении каких-либо участков кода (пример: «Achtung! 30% времени на подключение к MySQL»).


    Все выводы получены в результате личных наблюдений и тестов.
    Вполне возможно, что на вашей системе результаты будут иные.

    Замечу, что многое зависит от вашей архитектуры, и практически любой совет надо проверять на своём коде, не доверяя полностью чужому опыту.

    Поэтому я осознанно не указывал абсолютных цифр, которые вы можете найти и сами, к примеру на http://phpbench.com/ (не моё)

    Удачи и быстрого кода!
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну, и что?
    Реклама
    Комментарии 301
    • +2
      Сразу бросилось в глаза. Не count() алиас, а как раз наоборот — sizeof() есть алиас для count():
      ru2.php.net/sizeof
      • 0
        Спасибо, поправлю, переставил места в уме.

        time php -r 'for ($a=0; $a<10000; $a++) count($_SERVER);'
        php -r 'for ($a=0; $a<10000; $a++) count($_SERVER);' 0,04s user 0,01s system 90% cpu 0,055 total


        time php -r 'for ($a=0; $a<10000; $a++) sizeof($_SERVER);'
        php -r 'for ($a=0; $a<10000; $a++) sizeof($_SERVER);' 0,03s user 0,02s system 82% cpu 0,061 total
        • +1
          Это отсюда следует вывод
          sizeof() это синоним count(), работает быстрее

          ?
          Ну-ну…
        • +3
          Аааа, бросилось в глаза.
          Nobody cares ваще-то
          • –3
            а почему ru2, а не ru?
            • +2
              Не знаю, поддомен автоматом подставляется, я пишу просто «php.net/{function_name}», когда обращаюсь к мануалу.
          • +9
            Оптимизаторы, блин. Ну нет смысла гоняться за милисекундами, ясно ведь что это ничего реального не даст. А если будут реально мощные наргрузочки — по-любому придется масштабировать проект, далеко на профилировании PHP-кода с его последующей оптимизацией не уедешь.

            Вот вераня мысль на эту тему, полностью согласен с Котеровым:

            forum.dklab.ru/viewtopic.php?p=42214#42214
            • +18
              Например, 30 000 000 хитов в сутки * лишние 50-100 миллисекунд, это уже сотни часов серверного времени. Которые стоят денег.
              И эти сэкономленные часы, могут отложить необходимость «железного» масштабирования, на месяц, может быть два.
              Если вы бутстраппер, и стараетесь минимизировать расходы, это может сыграть свою роль.

              Да и вообще, политики «тормозит — смени железо» и «главное — скорость разработки», приводит к тому, что в моей кубунте, питоньих скриптов скоро будет больше чем бинарников. Ничего против питона не имею, но реально — уже заметно тормозит.
              • +4
                Кстати, в данном случае, не Котерова надо цитировать, а Дональда Кнута, он всё-таки был раньше.
                • –11
                  Что значит «стоят денег»? Хостер что ли подсчитывает время и выставляет чек? Нет. Пример с кубунтой кстати совсем другого рода. Раз тормозит, значит есть смысл подумать об оптмизации. Именно в таком порядке!

                  А Кнут вообще-то программист несколько другого рода. У нас же веб, тут свои законы и принципы.

                  Если о цитатах, то вот ещё можно взять книгу Фаулера «Рефакторинг». Там он разбирает рефакторит пример кода и при этом намеренно допускает ухудшение его производительности. Разбивает один цикл на два, каждый из которых с тем же количеством итераций. И дает насчет этого достаточно подробный и внятный комментарий.
                  • +6
                    «У нас же веб, тут свои законы и принципы.»

                    Мы кажется диаметрально противоположны во мнениях.
                    В вебе, скорость загрузки, прямо влияет на продажи/регистрации/заказы.

                    В desktop-приложениях, обычно можно подождать, оно же уже стоит.
                    Это как разница между сферой услуг и производством.

                    Стоит денег, потому что секунды собираются в минуты, минуты в часы, и приходится увеличивать количество серверов.

                    По поводу Фаулера, ничто не мешает писать и быстро и понятно =)
                    • –6
                      В вебе, скорость загрузки, прямо влияет на продажи/регистрации/заказы.


                      Для десктопных приложений характерно наличие тяжеловесных ресурсоемких и долговыполняющихся операций. И в этом случае разница между оптимизированным и неоптимизированным кодом будет выражаться в минутах — что для юзера ощутимо. В вебе такого обычно не бывает. Отправил запрос — получил ответ. И тут разница выражается в долях секунды — конечному пользователю до них по-барабану.
                      • +2
                        Далеко не по барабану.
                        webo.in/articles/habrahabr/54-psychology-web-performance/

                        У нас всё-таки всё очень разное, и десктопы и минуты, думаю, мы не убедим друг друга ни в чём =)
                        • 0
                          Если конечно всё не настолько плохо что страница после 30 секунд полной тишины вылетает с таймаутом, бывает такое на перегруженных сайтах, и честно говорю раздражает куда больше чем если бы она открывалась 60 секунд, но открывалась бы рано или поздно…

                          Но это касается развлекательных сайтов, если интернет магазин, проявляет признаки «тормозов» я незамедлительно иду в другой магазин.
                          (При покупке той или иной вещи, мне нужно быстро ознакомиться с вариантами. Ждать по 3-5 секунд каждую страницу, это отвратительно. Тем более что иногда информация о нужном товаре в 3-5 кликах, а если товаров ещё и несколько… Ужас короче.)
                      • +14
                        Пока программисты думают вот так:
                        А Кнут вообще-то программист несколько другого рода. У нас же веб, тут свои законы и принципы.

                        В вебе останется куча жуткого говнокода, за который надо расстреливать.
                        • +8
                          Да, и нормальным PHP-шникам, придётся продолжать объяснять, что они не быдлокодеры, и ничем не хуже других.
                          • +5
                            Как я вас понимаю.
                            Для многих PHP равняется быдлокодерству, это печальная правда.
                            • +4
                              Ноги растут из того факта, что какой-нибудь вчера-прочитал-два-туториала-рубист, поискав работу пару месяцев, резко осознает, что не смотря на то, что он высшее существо, с синтаксическим диабетом, почему-то всем нужны быдло-PHP-шники.
                              (далеко ходить не надо, я сам вчера вакансию (Казань) опубликовал)
                              И у него начинается производство кирпичей.

                              Не холивара ради, но радует, что школота уже не считает PHP крутым, и идёт на более домохозяечные языки.
                          • 0
                            В вебе останется куча жуткого говнокода, за который надо расстреливать.


                            А нифига

                            Многих читателей отталкивает факт использования языка низкого уровня, но Кнут считает свой выбор оправданным, так как привязка к архитектуре необходима для того, чтобы можно было точно судить о таких характеристиках алгоритма, как скорость, потребление памяти, и т. д.


                            ru.wikipedia.org/wiki/%D0%98%D1%81%D0%BA%D1%83%D1%81%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F
                            • 0
                              В вебе нет привязкии к архитектуре?
                              • 0
                                А есть?
                                Вопрос немного странный, если веб работает на C++, через CGI, то вообще-то привязка будет.
                                Или вы что имели ввиду?
                                • 0
                                  Ну пока у вас десять посетителей в сутки, то никакой привязки конечно нет. А если у вас hi-load, то у вас постепенно и особенности PHP в ход начинают идти, и ORM улетает в небытие, а потом вдруг у вас форкнутый MySQL и собственный компилятор PHP.

                                  Просто большинству вебо-быдло-кодеров никогда не работать с такими проектами, как Facebook, от того и отношение такое. Это на малых проектах вы можете себе позволить докупать по серверу в месяц, а когда вам приходится покупать по сотне серверов в месяц, то каждая микросекунда приносит кучу сэкономленного бабла.

                                  Справедливости ради стоит отметить, что замена двойных кавычек всё-равно ничего не даст (:
                                  • 0
                                    Я примерно это и пытался донести, по поводу микросекунд и серверов.
                      • +15
                        Бля! Да вы сначала добейтесь такого кол-ва хитов, а потом говорите о производительности. Посещаемость сайтов обычно увеличивается экспоненциально. И оптимизировать вы станете не такие мелочи, а реально узкие места.

                        Использование разных хитрых конструкций для мнимого увеличения производительности ухудшает читабельность кода, не давая никаких плюсов на 99% сайтов.
                        • +10
                          Вы читали топик?

                          «Да вы сначала добейтесь такого кол-ва хитов, а потом говорите о производительности.»
                          Я не вчера пришёл в профессию, и, опыты были разные, и 30 000 000 qpd, это всего лишь 40 qps.
                          PHP, кстати, это не только сайты. Это, например, фронтенды систем сбора информации.

                          «Посещаемость сайтов обычно увеличивается экспоненциально.»
                          Ваш вывод основан на каких данных, с каких сайтов?

                          «хитрых конструкций»
                          Какая именно конструкция вам кажется хитрой? Я могу разъяснить.

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

                          «не давая никаких плюсов на 99% сайтов»
                          99% сайтов, не поднимаются выше 100 хостов в сутки, конечно же, эффект будет не заметен.

                          Вас что разозлило до состояния «Бля!»?
                          • +1
                            Просто люди и задачи бывают разные:
                            — те люди, которым посчастливилось запустить проект с огромной посещаемостью, как правило, уже познакомились с основами оптимизации и ваша статья не дала ничего нового;
                            — молодые разработчики, которые только начали свое вхождение в веб-разработку, обычно не делают ничего крупномасштабного: как правило это разработка всевозможных сайтов-визиток, промиков, и пр. «новости-статьи-фотогалерея-с-пхпББ-форумом». Посещаемость на таких проектах как правило крайне мала (ура! сегодня приходил яндекс-бот), тонкая оптимизация их не интересует, работы и так много — надо срочно дописать свою ЦМС. Часть из них что-то усвоит и скажет вам спасибо, остальные хабр возможно и не читают :)
                            — студенты-нерды: зазубрят каждую сторчку вашей статьи и будут «оптимизировать» где только можно и нельзя в своих лабораторных работах (не забыв заменить все двойные кавычки на одинарные!). Такие люди имеют шанс впоследствии стать неплохими специалистами, когда со временем придет опыт и юношеский пыл поутихнет (если не увлекутся чем-нибудь еще и не уйдут в другую отрасль).

                            Вывод: в первом случае цена железа может оказаться меньше стоимости оптимизации, во-втором случае оптимизация обычно не проводится (даже если нужна), в третьем нужна оптимизация или не нужна — не важно, она там будет, ибо fun.
                            • +3
                              Надеюсь, никто не будет зубрить мою статью.

                              Оптимизация, может быть не отдельным процессом, а больше стилем, вот я о чём.
                              • +2
                                Если вы про то, чтобы научить себя сразу писать оптимально и красиво, то да, это хороший стиль!
                                • +1
                                  Именно про это, в противовес подходу «пойду-ка напишу скрипт для замены всех count и sizeof».
                                • +2
                                  Что в вашем понимании «стиль» применимо к оптимизации? Писать «simplexml_load_string( file_get_contents ('file.xml') )» вместо «simplexml_load_file('file.xml')»? Без дополнительного комментария рядом это — WTF.

                                  Поймите: единственно верной статьей по оптимизации PHP может быть описание как пользоваться профайлером и описание где искать информацию по оптимизации базы и кеширования.
                                  • +2
                                    Единственно верным и надежным способом является набить всем шишки самому.
                                    Но люди, зачем-то обмениваются знаниями и наблюдениями.
                              • 0
                                «фронтенды для сбора информации» чаще всего вообще-то переписывают на С++ :)
                                • 0
                                  Я не про высоконагруженные сенсоры, а про проекты попроще, где важна универсальность и удобство PHP.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                • +1
                                  Делать код быстрее имхо лучше чем делать «как знают все». Тыделаешь сайт для посетителей или для разработчиков?
                                  • –1
                                    Почитайте что-нить нормально по оптимизации (например: habrahabr.ru/blogs/php/22881/) и не пишите чушь.
                                    • –1
                                      По книжке конечно жить хорошо, но опечатки могут тебя подвести.
                                      В серьезных проектах уже не действуют те законы оптимизации, которые можно применять к стандартным студенческим сайтам. К примеру проектирование базы данных — кардинально отличается… — как пример запросы на обычном не нагруженном сайте могут выглядеть как связка 2 -х 3-х и более таблиц, что довольно часто недопустимо на мега-проектах (я бы сказал веб системах) — там это может делаться в 2-3 отдельных запроса.
                                      Типичный пример — эта статья — поверь, человек не просто дурью маялся. И иногда посидеть часок-другой над таким рефакторингом намного выгоднее чем платить лишнюю тысячу долларов на новый процессор или сервер.
                                      • +2
                                        Закон оптимизации только один — профайлинг. Других нету. Действует везде.
                                        Профайлинг приложения в целом, а не искусственного кода на однопользовательской машине.

                                        Человек именно что маялся дурью.
                                        Тe самые запросы выполняются в миллионы раз дольше, чем высиженная здесь мифическая разница между count и sizeof. Весь этот «рефакторинг» высосан из пальца. И оптимизировать надо их, а не это фуфло.

                                        Рефакторинг, my ass. Вот ты аффтару подсуропил. Он-то пытается сейчас закосить под девочку, выставить свои поучения как ни к чему не обязывающие советы, типа «Ну если все равно какую функцию использовать, то лучше „более быструю“. На этапе разработки, разумеется. Но даже он и в кошмарном сне себе не представит, что по его статье надо срочно садиться и перепахивать весь код на использование „более быстрых функций“.

                                        Продолжай его защищать. С такими друзьями врагов не надо :)
                                        • 0
                                          Я не хочу с вами спорить, т к закон законом, но дело не в том. Это не подмена законов и т д, это дополнительные возможности сэкономить на железе, времени и деньгах.
                                          Если вы исключаете для себя еще одну возможность ускорить свой код — продолжайте ограничивать себя дальше.
                                          • +2
                                            В то-то и дело, что нет тут никаких дополнительных возможностей.
                                            Даже автор уже изъюлился весь — «летают, но нызенько-нызенько! На разных осях/сборках/машинах все будет по-разному!!» Ну и толку-то тогда в этих советах, если у соседа они приведут не к экономии, а к расходам?
                                            На самом деле — бред, конечно. Ни к экономии, ни к расходам этот набор заклинаний не имеет никакого отношения.
                                            Дело не в том, какая функция быстрее или медленнее. А в том, что эта разница не влияет на конечный результат. Ключевое слово — конечный результат. На конечном результате мы получим неразличимую разницу — в пределах погрешности.
                                            Это очень сложно понять тому, кто ни разу не пользовался профайлингом и не научился отличать значимое от незначительного. Но рекомендую хотя бы попытаться.
                                            • 0
                                              Ты клёвый, ты столько про меня знаешь, я уже привязался к тебе =)
                                              • 0
                                                сами то не юлите? Туда сюда, конечный результат… Профайлинг — профайлингом. Писать то надо уметь, чтобы понять почему что-то тормозит.
                                                • 0
                                                  Тупо отрицать то что работает. И если ты немного подумаешь, а не будешь прикрываться законами, то может поймешь, что можно применять и в большинстве случаев успешно.
                                                  Не как основное, а как дополнение.
                                                  Конечно можно орать что лучше когда сразу через хDebug все прогнать.
                                                  Есть куча возможностей по ускорению проекта на других уровнях (redis, memcached, memory tables, ssi, nginx) — но никто же из-за этого не отменяет оптимизацию.
                                                  Не будь ограниченным, бо из-за таких рамок можно пропустить очевидные вещи, которые могут ускорить проект.
                                                  • 0
                                                    ну нашёл ты узкое место, а дальше что? а дальше открываем подобную статью и смотрим что в этом узком месте можно соптимизировать.
                                                    • 0
                                                      Нет-нет! ни в коем случае!
                                                      Здесь это не работает.
                                                      Вот и автор даже сам уже сто раз повторил, что на других системах все будет по-другому (какой тогда вообще смысл было писать — это другой вопрос). То есть, он сам же и пишет, что НЕ НАДО обращаться к его статье.

                                                      Оптимизация — это процесс. Её нельзя просто «добавить». В каждом конкретном случае надо действовать по-разному.
                                                      Хороший пример — база данных.
                                                      Плохая статья напишет «добавь индекс на поле, по которому идет поиск». Хорошая — «изучай эксплейны для твоего КОНКРЕТНОГО случая». Это не всегда занимает 5 минут. Но это то, что реально помогает, и то, что приходится делать.

                                                      Но вообще, конечно, это все пустое. Подавляющее большинство комментаторов никогда в жизни не столкнутся с необходимостью опртимизации, а столкнувшись — будут решать ее совсем другими средствами. Не зря на форумах так много вопросов «какая самая ыбыстрая CMS»
                                                      • 0
                                                        без статьи я бы и не узнал, что file_get_contents может быть быстрее file. как бы я об этом узнал читая эксплейны? или предложишь открывать исходники этих функций?
                                              • 0
                                                Найди слово рефакторинг в моей статье, потом с удовольствием выслушаю извинения, и рассуждения о «высосанности из пальца».
                                              • 0
                                                Что вам, что автору сего топика советую прочитать Макконнелла «Совершенный код», раздел про оптимизацию. Там очень хорошо показано почему рулит профайлинг живого кода и почему никогда не следуют делать синтетические тесты для попыток что-то там померить.
                                                • 0
                                                  Цитату из топика приведу:

                                                  «Замечу, что многое зависит от вашей архитектуры, и практически любой совет надо проверять на своём коде, не доверяя полностью чужому опыту.»
                                                  • 0
                                                    Тогда еще раз повторю: единственно верной статьей по оптимизации PHP может быть описание как пользоваться профайлером и описание где искать информацию по оптимизации базы и кеширования.

                                                    Раз приходится делать подобные микро-оптимизации, у вас узкое место — PHP. Смените язык и не страдайте фигней. Много кода, слишком долог будет перенос на другую технологию? Ок, напишите модуль к PHP на С.

                                                    Та же самая Java, если ее знать, ничуть не медленнее для разработки сайтов, а вот в плане отладки и скорости выполнения обгоняет PHP на *порядки*.

                                                    Вы работаете с языком очень высокого уровня. Основные оптимизации — алгоритмы, архитектура, смена языка. Микро-оптимизации не принесут достаточного эффекта, чтобы о них даже задумываться.
                                                    • 0
                                                      Кстати, как раз уже неделю, изучаю JSP + Tomcat, java поражает скоростью, хотя пока непривычно.
                                                • +1
                                                  LOL
                                                  как я и говорил — аффтар тобой недоволен. Найди, говорит, слово «рефакторинг» в моей статье и извинись!
                                                  лизать-то тоже надо с умом, хе-хе
                                                  • 0
                                                    Я выражаю свои мысли (не всегда совпадающие с автором), которые доказал.
                                                    Отгадай такую задачку:
                                                    У тебя есть 5 спичек. Как сложить из них 4 треугольника так чтобы они не пересекались?
                                                    (Ответ — посмотри на них в трехмерном пространстве тогда помешь как это сделать)
                                                    Вывод:
                                                    Если ты смотришь на проблему в одной плоскости — успехов.
                                          • +8
                                            пардон, конечно, но чтобы выиграть на нагруженном проекте 100мс путём таких оптимизаций — нужно чтобы код был совсем уж лапшой.
                                            • –2
                                              Очень просто, к примеру strtr в некоторых случаях (короткие аргументы), оказывается быстрее группы str_replace.

                                              Как вы думаете, средний шаблонизатор, сколько делает замен за запрос?
                                              • +2
                                                1. Я комментировал статью, не надо придумывать на ходу другие примеры. Я прекрасно знаю, как ещё можно оптимизировать код. Я лишь уточнил, что примерами из статьи вряд ли удастся оптимизировать проект, который работает на 40rps (пускай загрузка будет равномерной). Итого — по 25мс на запрос. Т.е. оптимизировав код на 100мс, вы получится время выполнения (барабанная дробь) = -75мс. А теперь ещё добавим неравномерную загрузку и получим ещё более обескураживающие результаты

                                                2. Если strtr в некоторых случаях и выигрывает, то, логично предположить, что в некоторых — проигрывает. Как вы будете производить выборку рантайм и какова будет итоговая маржа — тоже стоит лишь гадать. И на вашем месте про 100мс на указанных нагрузках я бы таки не вспоминал.
                                                • 0
                                                  ps: я вам поверил, а вы ошиблись — 30M rpd == 347.(2) rps, т.е. 2.88ms на запрос. Где вы тут оптимизируете на 100мс — ума не приложу.
                                                  • 0
                                                    Да, насчёт 40qps, я ошибся, это нагрузка у текущего проекта, сорри.

                                                    Число 100 было выбрано без задней мысли. Знаете, некоторые люди, называют хайлоудом проекты, у которых 2400ms на страницу.

                                                    Ситуация сильно меняется, если это выигрыш 10ms?
                                                    Если не ошибаюсь, там получается выигрыш в несколько сотен часов, и сути дела это не меняет.
                                                    • +1
                                                      Суть дела меняет.

                                                      2.4s на запрос (забудем о нюансах) — это максимум 36rpd
                                                      2.39s на запрос — это максимум ~36151rpd

                                                      Для меня эта разница не принципиальна. А для вас? Ах, да — указанные 30М хитов проект с такой производительностью наберёт за 833.(3) дня. Т.е. за 2.28года. Выигрыш в 83.(3) часа (3 суток) за более чем 2 года — это насмешка над командой оптимизаторов.
                                                      • 0
                                                        Извините, я немного не понял, как 36rpd из 2.4s получилось.

                                                        Это 36 requests per day?
                                                        • +1
                                                          36k, забыл суффикс. Это ведь очевидно. По вычислениям, кроме опечатки, есть претензии? :-)
                                                          • 0
                                                            Нет, это не претензия, я просто не понял =)

                                                            По поводу вычислений, соглашусь, но вам не кажется, что еще важна площадь кода?

                                                            И да, для меня это критично, чисто из перфекционизма, наверное. =)
                                                            • +1
                                                              Я не против вашего подхода — я сам пользуюсь (исторически и интуитивно) почти всеми техниками, что и вы описали — мне просто не совсем понятен подобный подход к изложению. Лично я считаю, что новички сами должны до этого всего дойти, наступив на сотни граблей. В конце-то концов, у начинающих программистов нет таких нагрузок, где подобные спичечные оптимизации были бы эффективны, а для неначинающих вы Америку и не открыли…

                                                              Хотя я уже придираюсь, скорее, согласен )
                                                              • 0
                                                                Во, понял что я хотел сказать, но никак не мог: ваши советы стоит преподносить как best practices, но не как руководство к действию при оптимизациях скорострельности.
                                                                • 0
                                                                  Ну, теперь всё ясно, мир? =)
                                                                  • +1
                                                                    Мир, да. Я сам к этому выводу пришёл только сейчас. Если с него и начинать — много времени бы сэкономили :-)
                                                                  • 0
                                                                    bullshit это называется, а не best practices
                                                                    обычные нубские рассуждения на тему «прирост в 5-10 раз!!!».
                                                                    Что бы он ни лепетал в оправдание, но в головах у «джуниоров» оптимизация все равно останется не процессом, а набором цитат Мао. заменил инклюд_онс на инклюд — и порядок. ПОДХОД неверный в принципе.
                                                                    О банальных вещах, вроде «одинарные кавычки вместо двойных», думаю, знают все, my ass. После этой фразы УЖЕ можно дальше не читать, все и так ясно. Че-то ты тормозишь. Не расшаркиваться надо, а запинать и поставить на место. Карму бережешь? нуну.
                                                                    • +2
                                                                      Могу нахуй послать, чтоб не было подозрений в кармадрочерстве, успокоит?
                                                                      Нубские, наверное, даже будучи php-кодером 7-ой год, я рад, что мне есть куда расти, и чему учиться.

                                                                      Кстати, попробуй переспать с живой женщиной, ну хотя бы с платной.
                                                                      Это снимет болезненные приступы немотивированной аггрессии к незнакомым тебе людям. С правой рукой ты такого не добьешься, я гарантирую это =)
                                                                    • –3
                                                                      Чувак сливается сплошь и рядом.
                                                                      habrahabr.ru/blogs/php/102598/#comment_3188263
                                                                      «летают, но нызенько-нызенько»

                                                                      Фееричное, в соскдних предложениях:
                                                                      1) «Даже на Debian и Ubuntu, PHP иногда ведёт себя по разному».
                                                                      2) «Тут просто список особенностей поведения.»
                                                                      Фигли писать список особенностей (зачем он вообще нужен — другой вопрос), если сам же тут же говоришь, на разных системах особенности даже не воспроизводятся.

                                                                      Тут не сюсюкать надо. Тут за шкирку и в кучу носом натыкать.
                                                                      • 0
                                                                        Неделя свободы осталась, понимаю Вас, беснуйтесь дальше.

                                                                        1. Да, это распространённое явление, мейнтенеры могут иметь разные взгляды на параметры сборки.
                                                                        2. Я указал список систем, которые наблюдал, и отметил, что могут быть отличия.

                                                                        По поводу сюсюкания.
                                                                        Ваша сила в интернете, как всегда повергают меня в благоговейный страх.
                                                        • 0
                                                          Э… Вы собираетесь 30М запросов отдавать в один поток?

                                                          Уже всего на сотне потоков получается 288мс на запрос :)
                                                          • 0
                                                            1. У вас есть сто процессоров?
                                                            2. У вас все ресурсы так офигенно масштабируются: hdd, сеть, сторадж?
                                                            • 0
                                                              1. У меня четыре ядра и несколько сот потоков.

                                                              2. Именно потому, что ряд ресурсов не масштабируется, у меня несколько сот потоков. И 16Гб оперативки (ибо она «масштабируется» куда лучше, чем HDD).



                                                              30, не 30, но несколько миллионов запросов в сутки я отдавал даже на древнем Xeon-1800. И до 80-90 млн. SQL-запросов в сутки.
                                                        • 0
                                                          1. Вы отлично умеете придираться к цифрам, выдирая их из контекста. Я к слову, не указал в статье абсолютных цифр, чтоб таки не провоцировать таких вот споров.

                                                          2. Можно заранее знать, например, если это код, который превращает текстовые смайлики в графические.
                                                          • –1
                                                            Правильно, вы указали их в комментарии. И я дал ответ на комментарий в контексте поста. Ваши необдуманно брошенные слова спровоцируют миллионы новичков на новые «подвиги».

                                                            2. Можно. Приведите цифры из конкретного проекта, в котором замена str_replace была решающей и в которой был bottle neck.
                                                            • –1
                                                              «Ваши необдуманно брошенные слова спровоцируют миллионы новичков на новые «подвиги»»

                                                              Вы меня с Котеровым не путаете? Какие еще миллионы?
                                                              Вы сейчас, хотите, чтобы я сверхъественным образом отредактировал свой комментарий?
                                                              Или вы хотите, чтоб я раскаялся?

                                                              Я уже сказал, что цифра была выбрана абстрактно, моя ошибка, что это было неочевидно.

                                                              2. Те же смайлики, а также парсинг коротких тегов, позволяли сократить среднее время обработки на 10-15%, думаю, абсолютные числа с моего ноутбука или VDS вам не нужны?
                                                              • –1
                                                                Опять 10%. Опять необдуманно? Вы какой пример имеете ввиду — который 300rps, или который 2400ms на генерацию?
                                                                Если первый — тогда вы опять лжёте.
                                                                Если второй — тогда там есть куда более явные проблемы, чем поиск-замена смайликов.
                                                                • –1
                                                                  «Опять лжёте.»,
                                                                  У меня, извините, слов нет, после таких заявлений.

                                                                  Пример взял из своего конкретного кода, 20 ms -> 18 ms, устраивает? Может сорцами сверкнуть? =)

                                                                  Просветите насчёт явных проблем, если уж решили идти до конца.
                                                                  • 0
                                                                    Явные проблемы — это 2400ms на страницу. Если только там нет в том же потоке кодирования видео/картинок/звука или математики — это уже запашок.
                                                                    • 0
                                                                      Эээ, могу в личку вам скинуть ссылку на популярный движок для городских сайтов, который даёт такие результаты на конфигурации 8 ядер/8 гигов.
                                                                      • 0
                                                                        Не, меня изкоробочные CMS и прочие блогодвижки не интересуют. Да и никогда в жизни не интересовали :-)
                                                                        • 0
                                                                          Меня тоже, свой код держу в пределах 25-50 ms, но пришлось поддерживать эту жуть.
                                                        • 0
                                                          ни одной.
                                                          • 0
                                                            покажи такой
                                                            • 0
                                                              да любой
                                                              • 0
                                                                ну какой, например?
                                                                • 0
                                                                  смарти
                                                                  • 0
                                                                    grep -c 'replace' /usr/share/php/smarty/*
                                                                    /usr/share/php/smarty/Config_File.class.php:2
                                                                    /usr/share/php/smarty/debug.tpl:0
                                                                    /usr/share/php/smarty/internals:0
                                                                    /usr/share/php/smarty/libs:0
                                                                    /usr/share/php/smarty/plugins:0
                                                                    /usr/share/php/smarty/Smarty.class.php:3
                                                                    /usr/share/php/smarty/Smarty_Compiler.class.php:31
                                                                    • 0
                                                                      $property_name = preg_replace_callback('/([A-Z])/', $camel_func, $property_name);

                                                                      и чо?
                                                                      • 0
                                                                        /usr/share/php/smarty/Smarty_Compiler.class.php:
                                                                        $compiled_content = str_replace($tag_guard, '<?', $compiled_content);

                                                                        А вот чо.
                                                                        • 0
                                                                          и сколько раз на странице происходит перекомпиляция шаблонов? х)
                                                    • 0
                                                      сразу вопрос — а тестировалось-то с каким-нибудь компилятором?! тот же APC или еще что. А то вроде как про 30 млн хитов речь, а вот про тесты не понятно.
                                                      • 0
                                                        Цифры для иллюстрации, не с тестов.
                                                        • 0
                                                          Вопрос кстати не сразу понял. Вообще, xCache стоит.
                                                      • 0
                                                        Ну иногда проблемы бывают далеко не в базе, как посмотришь иногда на чужой код, так диву даёшься как это вообще ещё живо.
                                                        • +3
                                                          Я думаю, каждый хоть раз видел код, в стиле:
                                                          for ($a = 0; $a < count ($arr); $a++) do();
                                                          • 0
                                                            Я кстати тестировал подобную конструкцию на произваодительность. Как оказалось, главный тормоз здесь — вычисление count ($arr) на каждой итерации цикла. Ну это так, к слову.
                                                            • +2
                                                              Кхм, вообще-то это как раз таки пример хрестоматийно медленного кода, и проблема с count() очевидна =)
                                                              Или это была ирония?
                                                              • 0
                                                                Да нет, просто я сам в свое время понял, что главный тормоз здесь это count() только после того как сравнил результат с кодом, где count() вычислялся один раз. Не сказал бы что это настолько очевидно.
                                                                • –1
                                                                  Если что, я не минусую оппонентов.
                                                            • 0
                                                              Я бы тут предъявы кидал к интерпретатору, а не к разработчику.
                                                              • 0
                                                                Тут всё однозначно, причём тут интерпретатор?
                                                                Даже если он внутри кеширует результат каунта, то не стоит списывать со счётов расходы на вызов функции.
                                                                • 0
                                                                  А Common subexpression elimination происходить не должен?
                                                                  • 0
                                                                    Насколько я помню, это из теории компиляторов.
                                                                    В PHP видимо посчитали, что для интерпретатора такая замена не нужна.
                                                                    • 0
                                                                      Я к тому, что если $arr внутри вызова $do не модифицируется, я ожидаю, что нормальный компилятор сделает так:
                                                                      $tmp_arr_count = count ($arr)
                                                                      for ($a = 0; $a < $tmp_arr_count; $a++) do();
                                                                      


                                                                      Если вдруг выяснилось, что он этого не делает, и у меня вдруг это вылезет как узкое место, я скажу «гм» и сделаю это сам. Но только если вылезет на профайлере. Вообще странно ожидать такого от программиста.

                                                                      Это какой-то каменный век. Типа древного
                                                                      Inc
                                                                      в Borland Pascal. Компилятор разворачивал оператор:
                                                                      i:=i+1;

                                                                      в машинный код
                                                                       mov ax, [i]
                                                                       inc ax
                                                                       mov [i], ax

                                                                      вместо того, чтобы делать:
                                                                      inc [i]

                                                                      Чтобы получить нормальный код, была специальная функция-макрос:
                                                                      Inc(i);
                                                                      • 0
                                                                        Компилятор — это компилятор, у него во-первых есть время делать такие оптимизации, во-вторых есть возможность, так как чаще всего компилируемые языки — со статической типизацией, массивами, а не хешами, с ограниченной размерностью этих самых массивов и т.д.
                                                                        for($a = 0; $a < count($arr); $a++) {
                                                                          array_push($arr, 'newvalue');
                                                                        }

                                                                        И оптимизация ломает логику, а в php это вполне себе работающая конструкция.
                                                                        • 0
                                                                          Я же написал, если do() не модифицирует $arr. Определить это в большинстве случаев можно.
                                                                          В том числе и в языках с динамической типизацией и хитрыми массивами (javascript)
                                                                          • 0
                                                                            Это не всегда возможно, и не всегда доступно малой кровью, нежели гадать настолько-ли умен компилятор чтобы додумать программу за меня — мне проще написать самому for($i = 0, $j = count($array); $i < $j; $i++);, так как я-то точно знаю изменяется-ли размерность массива внутри цикла или нет.
                                                                            • 0
                                                                              Не надо ничего гадать, надо писать самым прямым способом. Если это было узкое место — оно на профайлере вылезет.
                                                                              Если язык поощряет писать «непрямым» способом, значит что-то не так.

                                                                              В данном случае не с языком, а с интепретатором.
                                                                              • 0
                                                                                Так предложенный мной способ — он и есть прямой, даже на компилируемых языках писать так — правильно, несмотря на то что на них отследить подсчет цикла более реально. Си-подобный цикл for выглядит так:
                                                                                for(инициализация; условие; инкремент); — первое выражение выполняется единожды, последующие два с каждой итерацией, вынесение count() во второе выражение указывает что он и будет выполнятся каждую итерацию, то что какие-то компиляторы могут на достаточном уровне проанализировать код чтобы понять будет-ли изменяться размерность массива — еще не значит что так и надо писать.
                                                                                Писать надо так, как оно в итоге должно выполнится, а не гонять потом программу в профайлере туда-обратно «угадал — не угадал?».
                                                                                • 0
                                                                                  Писать так, как оно «в итоге должно выполнятся», не надо.

                                                                                  Компилятор — программа, созданная, чтобы упрощать мою работу. Программист должен писать «что нужно сделать», а не «как это нужно сделать». Чем более высокий уровень — тем больше простора мы даем нижним уровням для оптимизации.

                                                                                  В этом плане лучше всего написать foreach, на самом деле.
                                                                                  • 0
                                                                                    Интерпретатор — не компилятор, как я уже выше написал, у компилятора гораздо больше времени проводить оптимизации, от него никто не ждет результата здесь и сейчас, он может анализировать код часами, насчет «что нужно сделать» и «как нужно сделать» — это споры насчет империтивного и функционального программирования, обе методологии имеют право на жизнь, но «что нужно сделать» относится ко второй, а php — к первой.
                                                                                    Ну и мои хвалебные оды foreach в конце топика :P foreach — это правильный пример оптимизации и облегчения жизни программиста, это отдельная языковая конструкция у которой заведомо известно что и как она исполнит.
                                                                                    • 0
                                                                                      У других интепретируемых языков CSE есть. Не везде, но в hotspot — есть.

                                                                                      Да, я тоже в общем случае за foreach, именно потому что, она более высокоуровневая.
                                                                          • 0
                                                                            Кстати, простите тупого, а этот цикл закончится? Мы на каждом шагу добавляем новое значение и никогда не догоним count($arr). Или я чего-то не понимаю?
                                                                            • 0
                                                                              Закончится по истечению 30 секундного интервала, если через set_time_limit() не задан другой интервал, это в данном случае актуально?
                                                                              • +1
                                                                                Это я на всякий случай. :)
                                                                          • +1
                                                                            Компилятор может вынести результат count() за пределы цикла только если будет знать что выращение внутри count() не меняется во время выполнения цикла. Если для простого скрипта вывода это проверить можно, то для многопоточных выражений — нет. Поэтому в данном случае «оптимизация» — за программистом.
                                                                            • 0
                                                                              Для к-каких извините, многопоточных выражений? Если $arr не глобальная переменная, то как она может существовать в другом потоке?
                                                                          • 0
                                                                            Ну и что значит «не нужна». CSE даже javascript интерпретаторы делают, а им вдруг не нужна.
                                                                      • 0
                                                                        имхо оставлять без особой необходимости в цикле вычисления которые из цикла можно вынести это писать плохой код.
                                                                        компиляторы/интерпретаторы тут не виноваты.
                                                                        • 0
                                                                          Ага, давайте так:
                                                                          foreach ($arr as $el)
                                                                          {
                                                                             echo $el + 1/3;
                                                                          }

                                                                          Я правильно понял, что в этом цикле каждый раз будет выполнятся деление с плавающей точкой? И нужно писать на самом деле вот так:

                                                                          $one_third = 1/3;
                                                                          foreach ($arr as $el)
                                                                          {
                                                                             echo $el + $one_third;
                                                                          }
                                                                  • +2
                                                                    Мне вот тоже казались, что рассуждения какие кавычки быстрее в приличном обществе давно запрещены.
                                                                  • +4
                                                                    Если я правильно понимаю, то в этом посте не содержится советов по той самой «преждевременной оптимизации, что является корнем всех зол». Здесь рассмотрено несколько правил, улучшающих производительность не в ущерб разработке — т.е. использование более быстрых синонимов/аналогов, не ухудшающих читабельность кода.
                                                                    • +3
                                                                      Да, преждевременная оптимизация, обычно связана с неуместным усложнением архитектуры кешированием, предвыборками и т.п.
                                                                      • 0
                                                                        Это тоже верно — если конструкции выглядят одинаково адекватно — почему бы и не применить наиболее быструю. Но вот о чем подумает новичок, прочитав такую статью? Он конечно же воспримет её как руководство к преждевременной оптимизации.

                                                                        Например, нотисы. Почему их нужно избегать? В первую очередь — не из-за оптимизации! Допустим, некий прогер разработал проект в котором решил забить на нотисы. Т. е. начал написал код так, что нотисы возникают и это считается для него нормальным тоном. Все равно на продакшне display_errors = off. И тут оказывается что логи сервера разбухают непомерянно — на каждый хит нотисов вылезает десяток штук. Устанавливаем error_reporting пониже — получаем проблему с дебагом кода.
                                                                        • 0
                                                                          Я указал, что если аргумент с хорошим тоном не прокатывает, но программист беспокоится о скорости, это еще один рычаг воздействия, ни в коем случае, не первостепенный.

                                                                          «Он конечно же воспримет её как руководство к преждевременной оптимизации.»
                                                                          Мне кажется, это слишком однозначный вывод.
                                                                          • –2
                                                                            На самом деле, конечно же, тоже неверно.
                                                                            Большая часть всех этих «оптимизаций» не приведет к измеримому приросту скорости работы приложения.
                                                                            И не выглядят они одинаково. С какой стати include_once стал выглядеть, как include? Оператор выбирается по требуемому функционалу, а не потому что какой-то дядя сказал, что один быстрее другого.
                                                                          • 0
                                                                            Нет, содержится.
                                                                            Преждевременная оптимизация — это именно стремление оптимизировать там, где не надо.
                                                                            Причем, что забавно — реально производительность как раз не увеличивается.
                                                                            Вбор между count и sizeof может быть обусловлен чем угодно, но только не разницей в производительности.
                                                                            Сам подход в принципе неверен. Вместо профайлинга, который и является единственным основанием к оптимизации, тут просто набор рецептов.
                                                                            Оговорка «на вашей системе результаты могут быть другими» выдает автора с головой. Это именно попытка преждевременной оптимизации и ничто другое.
                                                                            • +1
                                                                              Слушай, срыв покровов прямо какой-то.
                                                                              Я всегда думал, что преждевременная оптимизация, это стремление оптимизировать не тогда когда надо, как бы преждевременно. А ты мне глаза открыл =)

                                                                              Даже на Debian и Ubuntu, PHP иногда ведёт себя по разному, чего говорить о мире RPM-based дистрибутивов.
                                                                              Опять же, у меня нет под рукой FreeBSD, а на ней есть свои особенности.
                                                                              Поэтому там и есть эта оговорка.

                                                                              Набора рецептов, или практик, тут не было, вам показалось. Тут просто список особенностей поведения.
                                                                              Каждый сам определит для себя их полезность.
                                                                          • +16
                                                                            Мы тут вчера решили профайлером пройтись по одному проекту, доставшемуся нам от фирмы «X».
                                                                            400+ запросов к мускулу на 1 страницу. а вы тут на count() и sizeof() экономите…
                                                                            • 0
                                                                              Ну, подобные проблемы, слава богу, давно в прошлом.
                                                                              Я помню, в 2004 году, начинал писать свою систему на Athlon XP2400 / 256 RAM под windows, и у меня каждый лишний запрос, «кожей ощущался», можно было на вид определить сколько запросов было =)

                                                                              В следующих топиках, затрону тему правильной предвыборки и поствыборки из хранилищ данных.
                                                                              • 0
                                                                                Проект новый. компания довольно известна в городе екатеринбурге, но проблема есть
                                                                                клиент лучше будет платить за вдс с 1500мб памяти и кучей проца, чем один раз переделает сайт у фирмы с нормальными программистами. чтобы не быть голословным
                                                                                • 0
                                                                                  Да, это странно, платить каждый месяц, вместо единовременных оптимизаций.
                                                                            • +2
                                                                              Между прочим, от фразы «Преждевременная оптимизация — корень всех зол» недалеко ушла фраза «Как-нибудь сделаем, а потом исправим», и не надо путать одну с другой.
                                                                              • 0
                                                                                Да, вы очень правильно всё поняли.
                                                                                Одно дело, прикрутить memcached к начавшему тормозить mysql, другое, grep-ать и search&replace'ить весь код, заменяя куски кода.
                                                                                Это просто набор полезных ненапряжных привычек.
                                                                              • 0
                                                                                Пусть simplexml_load_file работает хоть в 2 раза медленнее, но он при чтении файла выглядит логичнее. Стало быть если в какой-то из следующих версий РНР может его и сделают быстрее, то ваш некогда быстрый код, как читался неудобно так и будет читаться дальше, а это сильно скажется на дальнейшей поддержке кода. Особенно это будет заметно с file()
                                                                                • 0
                                                                                  Приведу вам контр-пример.

                                                                                  У меня получение данных, абстрагировано классом, который скрывает реальный источник данных: БД, файлы, мемкешед, веб страница, и предоставляет единый интерфейс.

                                                                                  Я склоняюсь к соблюдению «unix way» и концепции «pipes» не только в целых скриптах, но и в функциях.
                                                                                  Мне нужна логика, которая разбирает xml. И только.

                                                                                  Как раз таки, когда мы берём под контроль процесс получения данных, мы повышаем гибкость и обслуживаемость кода, а не оставляем его на милость «может его и сделают быстрее».
                                                                                  • 0
                                                                                    Вот вы и сами в попытке опровергнуть моё мнение, только подтвердили его.

                                                                                    В вашем случае у вас совершенно другая ситуация, вам будет нужен file_get_contents, НО, не потому что он работает быстрее чем «simplexml_load_file», а потому что У ВАС в приложении просто архитектурно не предусмотрен таковой, и вы передаёте данные именно в «simplexml_load_string»!!!

                                                                                    Вывод?
                                                                                    Все эти советы имеют обратные стороны, использовать или нет зависит сугубо от ситуации, и скорость в миллисекундах или даже в микросекундах никакого отношения к этому не имеет…
                                                                                    • 0
                                                                                      Нет, не соглашусь всё-таки.

                                                                                      file_get_contents — он, образно выражаясь, специалист по получению файлов.
                                                                                      simplexml_load_file — дилетант, который хватается за два дела.
                                                                                • +1
                                                                                  Часто еще забывают, что множественная конкатанация строк — очень медленная операция.
                                                                                  вместо
                                                                                  $result='';
                                                                                  for($i=0;$i<=100500;$i++){
                                                                                  $result.='<option>'.$result.'</option>';
                                                                                  }

                                                                                  лучше сделать
                                                                                  ob_start();
                                                                                  for($i=0;$i<=100500;$i++){
                                                                                  echo '<option>', $result, '</option>';//при echo используем запятую между фрагментами, а не точку
                                                                                  }
                                                                                  $result=ob_get_clean();

                                                                                  • +1
                                                                                    Об этом хорошо очень на phpbench.com написано, советую.
                                                                                    В своей статье, я решил не повторяться, об этом часто пишут, и часто забывают.
                                                                                    • +1
                                                                                      На phpbench не увидел варианта, когда нужно в результате получить строку, а не вывести её. Как показывает опыт общения с программистами, ob_ функции очевидны далеко не для всех.
                                                                                      • +1
                                                                                        Мне кажется, в проекте echo должен быть только один, не смотря на преимущества ob_.
                                                                                        Тот, который выводит отрендеренную переменную.

                                                                                        Это повышает удобство отладки и ясность кода, имхо.
                                                                                        • 0
                                                                                          На сайтах портального типа я сторонник блочного построения страницы, когда у каждого блока свои настройки кэширования. При отсутствии нужного блока в кэше — он рендерится в строку и ложится в кэш в соответствии со своими настройками. Как такого достичь без буферизации вывода — я не знаю.
                                                                                          • 0
                                                                                            Я к примеру, использую класс, который вызываю вместо echo, а он сам раскидывает это по своим внутренним массивам и внешним кешам.
                                                                                            • 0
                                                                                              Можете описать чуть поподробней?
                                                                                              Например, есть страничка, на которой выводится телепрограмма (инвалидация в полночь), популярное видео (обновляется раз в час), последние новости (обновляется раз в 15 минут).
                                                                                              Как этого можно добиться классом, заменяющим echo?
                                                                                              • 0
                                                                                                Логичнее, наверное, в личку.
                                                                                                Сложно описать, не зная, какая у вас архитектура.
                                                                                            • +1
                                                                                              Легко — вместо echo использовать return!!! )))
                                                                                      • 0
                                                                                        А разве если я делаю echo сразу заголовки страницы не отсылаются пользователю?
                                                                                        Просто могут возникнуть проблемы, если их менять будут.
                                                                                        • +1
                                                                                          Если ob_start() включён, то echo можно делать спокойно.
                                                                                          Если нет, заголовки после echo вы не измените.
                                                                                        • 0
                                                                                          for($i=0;$i
                                                                                          • 0
                                                                                            Если output_buffering=off, то можно

                                                                                            $_temp = array();
                                                                                            for($i=0;$i<=100500;$i++){
                                                                                            $_temp[] = "<option>{$result}</option>";
                                                                                            }
                                                                                            $_temp = join('', $_temp);
                                                                                          • 0
                                                                                            Сравнивал в свое время скорость работы с public полем и вызова геттера/сеттера этого поля с работой магических методов __get, __set и __call.
                                                                                            Для 1000 итераций получились следующие значения (в секундах):

                                                                                            getFieldValue():0.0013
                                                                                            _field(получение):0.0003
                                                                                            __get():0.0010

                                                                                            setFieldValue():0.0014
                                                                                            _field(установка):0.0003
                                                                                            __set():0.0012

                                                                                            __call():0.0024


                                                                                            P.S. __get / __set / __call были реализованы следубщим способом:
                                                                                              public function __get($name)
                                                                                                {return $this->_field;}
                                                                                              public function __set($name, $val)
                                                                                                {$this->_field=$val;}
                                                                                              public function __call($name, $arg)
                                                                                                {return $this->_field;}