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

Сразу бросилось в глаза. Не count() алиас, а как раз наоборот — sizeof() есть алиас для count():
ru2.php.net/sizeof

Оптимизаторы, блин. Ну нет смысла гоняться за милисекундами, ясно ведь что это ничего реального не даст. А если будут реально мощные наргрузочки — по-любому придется масштабировать проект, далеко на профилировании PHP-кода с его последующей оптимизацией не уедешь.

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

forum.dklab.ru/viewtopic.php?p=42214#42214

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

Мы тут вчера решили профайлером пройтись по одному проекту, доставшемуся нам от фирмы «X».
400+ запросов к мускулу на 1 страницу. а вы тут на count() и sizeof() экономите…

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

Пусть simplexml_load_file работает хоть в 2 раза медленнее, но он при чтении файла выглядит логичнее. Стало быть если в какой-то из следующих версий РНР может его и сделают быстрее, то ваш некогда быстрый код, как читался неудобно так и будет читаться дальше, а это сильно скажется на дальнейшей поддержке кода. Особенно это будет заметно с file()

Часто еще забывают, что множественная конкатанация строк — очень медленная операция.
вместо

$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();

Сравнивал в свое время скорость работы с 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;}

Спасибо за пост. Мне, как и многим другим, кто стремится сделать свой код лучше и быстрее — такое полезно.

Было бы здорово увидеть обзор многих других функций и блоков php в их сравнительной скорости выполнения.

>>Скажу лишь, что перейдя на json-файлы для конфигурации…
А почему бы не хранить конфиги в нативных массивах php? Будет еще быстрее.

Вот, кстати, добавлял ваш пост в закладки — нашел рядом еще один от Ивана Блинкова:
www.insight-it.ru/programming/php/na-puti-k-idealu/

Насчет производительности множественной конкатенации строк осмелюсь оспорить. Если вы склеиваете много маленьких строк через массив — расходуется впустую память и процессорное время на операции с нею.

pastebin.com/Wz1QvZ74 — скрипт для тестирования предложеного мною случая и его вывод на моем сервере с php 5.3

warmup job: time: 0.003025 | memory: 606092
warmup flush: time: 0.003353 | memory: 532

array job: time: 0.002856 | memory: 605688
flush: time: 0.003168 | memory: 108

concat job: time: 0.001687 | memory: 100096
flush: time: 0.001697 | memory: 104

10к элементов по 10байт — в случае с массивами расход памяти в 6 раз больше, расход процессорного времени — 2 раза. Также заметно, что PHP требуется больше времени, чтобы освободить память после работы с массивом. Это тоже надо учитывать.

Склейку через массивы можно производить с большими строками (в webdev такое редко), а не преподносить как общую панацею от тормозов.

В моем случае я тоже склеивал раньше все через массивы, пока не перешел к более-менее серьёзным объемам, от которых пхп начал вываливаться за memory limit 256Мб, при объеме данных на 2-5Мб, кусочки были разные, 100-10Байт, просто их было много. Переход к тупой последовательной склейке строк дал мне расход памяти на эту операцию всего в районе 16Мб и немного увеличившееся время генерации содержимого.