FAQ по оптимизации PHP-скриптов

nginx+php as fcgi - очень неплохая оптимизация :)

Всегда пишу, оптимизируя код автоматом. Тоесть в уме всегда то, что нужно использовать как можно меньше ресурсов. Очень полезное качество=))

PS: Я вот админки к своим скриптам писать ненавижу=)) Всегда приходится управлять через phpmyadmin=))

KabancheG, Fcgi и с апачем неплохо дружит, просто наверное надо уметь ему готовить, но это не всегда возможно и не все знают как.

Всегда думал, что include - это вставка кода в момент исполнения скрипта, а require в момент подготовки скрипта для исполнения, т.е. require сперва собирает всё, а потом уже исполняет и потому получается быстрее, чем по ходу вставлять.

Кстати, по сабжу: sizeof() работает почему-то быстрее count(), хоть в документации и называются они алиасами, но факт...

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

P.S. Да, это экономия на спичках и мускуль с файлами затормозит любой скрипт, но именно такая экономия для меня считается нормой кодинга.

10 программируемых символов.

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

nikitian, про кавычки и sizeof() написано в статьях, которые в первом посте.

По моему сугубому мнению, все эти шаманства с print/echo, for/foreach причем с отрывом от контекста задачи дают такой же выхлоп, как и гадание на кофейной гуще.

Во-первых - не стоит оптимизировать раньше времени. Если все работает нормально, то скрипт лучше вообще не трогать. Т.е. задачу оптимизации надо решать по мере поступления.

Второе - надо оптимизировать не функцию/оператор, а саму логику приложения. Если начало тормозить - ставим счетчики, замеряем время, ищем "подозрительный" кусок, и только тогда начинаем править.

Третье - чаще всего тормоза - это перенормализованные БД, кривые запросы к ней же, неэкономичные алгоритмы обходов, но никак не конкатенация и прочая мелочевка :)

Реально имеет смысл оптимизировать алгоритмы а не выигрывать 0.00001 секунду заменяя count на sizeof. Если речь конечно идет именно о сайтах. Если же это некое сложное web-приложение (например поисковая система), то там уже и экономия на спичках даст хороший вес. По теме могу сказать, что очень хороший прирост производительности дает правильное использование ООП. Например взять тот же форум PHPbb - одни сплошные классы и в итоге весьма медлительный двигун. Я на своем опыте заметил, что нет смысла выносить функции частого использования в классы, если в итоге будет востребован только один экземпляр класса.

+100

Я на своем опыте заметил, что для WEB (простой сайт, новости, статьи, гостевуха, или даже блог) вообще не нужно ООП а исполняемые за раз скрипты в 99% случаях занимают 2-3кб

(при полной готовой к использованию CMS в 10-15кб не считая дизайна...)

По сути сайт (не сервис какой нибудь, а тупо информационный сайт) это лишь FrontEND для 2-3 таблиц БД