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

Наткнулся тут на статью в блоге alexatnet.com:PHP micro-optimization tips

Я решил перевести эти советы, а так же добавить свое мнение.

Не стоит тупо следовать чьим-то советам!!!

Например не все здесь применимо к ООП. Мы можем сделать все на функциях, т.к. они быстрее. Можем, правда? Мы сэкономим 2 миллисекунды при исполнении, при миллионе вызовов в секунду – экономим 2 секунды – много ли? Но насколько мы увеличим время разработки, при отказе от ООП??? Целесообразно ли???

Это самый яркий пример. Остальное по тексту – мои комментарии выделены

1. Вызов метода объекта быстрее вызова “__call” , но в момент написания кода мы не всегда знаем какой метод и какого объекта будет вызван
2. Вызов статического метода быстрее чем вызов метода объекта, а как же ООП, инкапсуляция, коллекции, итераторы и т.д. ? Без них можно разрабатывать, но гораздо дороже!
3. Вызов функции быстрее вызова статического метода, конечно, но только в том случае, если вы не знакомы с ООП. Тогда ваша разработка стоит для конечного заказчика гораздо дороже, а поддерживать код становится гораздо сложнее
4. Доступ к локальной переменной быстрее доступа к глобальной переменной – действительно так, да и не нужно выводить из локального контекста переменную, если в этом нет необходимости
5. Доступ к глобальной переменной быстрее доступа к свойству объекта, но глобальные переменные – зло!!!
6. Прямой доступ к свойству объекта быстрее чем вызов магических “__get” и “__set” , естественно, но во время написания кода мы иногда не знаем какие свойства будет хранить объект.
7. Доступ к инициализированной переменной быстрее доступа к неинициализированной. Да, это так! И рекомендую инициализировать все переменные – это хорошая практика предупреждения возникновения неожиданных ошибок.
8. Абсолютные пути в “include” и “require” быстрее относительных
9. Объединение нескольких скриптов в один быстрее, чем несколько include. Да! Но разобраться потом в одном огромном файле…. И еще: если каким-то скриптам нужны почти все классы библиотеки – это будет плюсом. Другим скриптам нужен только один вспомогательный класс – в этом случае скрипт будет дольше стартовать, чем исполняться, к тому же мы получим беспричинный расход памяти.
10. “switch” быстрее, чем “if … else if …” в большинстве случаев.Но я предпочитаю заменять switch на реализацию паттерна “стратегия”
11. Не используйте регулярные выражения для простых операций со строками
12. Избегайте @ (оператор подавления сообщений об ошибках)
13. Избегайте выбросов Notice и Warning в ваших скриптах
14. Избегайте неиспользуемых переменых и неиспользуемых параметров методов
15. Добавление параметра в метод увеличивает время вызова,однако без параметров никуда.
16. Добавление к параметру метода type hint увеличивает время вызова, но уменьшает время разработки, благодаря повышению читабельности кода, а так же уменьшает возможность возникновения трудно-обнаруживаемых ошибок.
17. Вызывайте unset для переменных, содержащих большое количество данных или циклические ссылки
18. $_SERVER['REQUEST_TIME'] включает время старта скрипта
19. Кэшируйте вывод скрипта или результаты жадных на ресурсы функций
20. “echo” быстрее, чем “print”
21. “echo” поддерживает несколько аргументов, используйте это вместо конкактенации
22. “ob_start()” и “ob_end_clean()” могут быть лучше чем конкактенация
23. Строки в одинарных кавычках (’…’) обрабатываются быстрее строк в двойных кавычках (”…”), т.к. в первом случае не производится интепретация переменных внутри кавычек.
24. pre-increment (++$i) быстрее, чем post-increment ($i++)
25. “isset” быстрее, чем “array_key_exists”
26. Массивы быстрее классов с несколькими полями. Так что если вы используете классы только для хранения данных (такое я наблюдал в drupal) – замените их массивами.
27. “foreach” лучше, чем “for” в большинстве случаев
28. Открывайте ресурсы (файлы, БД, сокеты) непосредственно перед их использованием, освобождайте (закрывайте) их сразу, как только они становятся не нужны
29. Не доставайте из таблиц БД поля, которые вы не будете использовать
30. Используйте prepared database statements ( я затруднился перевести эту фразу, хотя и понимаю смысл)
31. Объединяйте несколько запросов в один, если СУБД поддерживает такой подход

Думайте, как применять эти советы в вашем конкретном случае! Не бросайтесь тупо оптимизировать все ради еще одной свободной наносекунды!!!