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. Объединяйте несколько запросов в один, если СУБД поддерживает такой подход

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

Комменты

  • 03.05.2014 19:10:48 Makc:
    Автор, пожалуйста, перепиши пост с учётом здравого смысла и не дури людям головы!
    1) Вызов метода объекта быстрее вызова “__call” , но в момент написания кода мы не всегда знаем какой метод и какого объекта будет вызван
    Имеется ввиду магический метод __call, который вызывается при обращении к методу, который не определён в классе, а не что-то вроде call_user_func (о чём, видимо, подумал автор)
    2) Вызов статического метода быстрее чем вызов метода объекта, а как же ООП, инкапсуляция, коллекции, итераторы и т.д. ? Без них можно разрабатывать, но гораздо дороже!
    Имеется ввиду статический метод класса, а не процедура. А вызывается он быстрее из-за особенностей процесса компиляции.
    3) Вызов функции быстрее вызова статического метода, конечно, но только в том случае, если вы не знакомы с ООП. Тогда ваша разработка стоит для конечного заказчика гораздо дороже, а поддерживать код становится гораздо сложнее
    Тут я согласен, но идея в том, чтобы не пихать классы (тем более паттерны) везде где ни попадя. Например для вывода года копирайта глупо писать класс.
    6) Прямой доступ к свойству объекта быстрее чем вызов магических “__get” и “__set” , естественно, но во время написания кода мы иногда не знаем какие свойства будет хранить объект.
    “__get” и “__set” используются для более тонкой "настройки" процесса присваивания/доступа, например, ц их помощью можно делегировать доступ к переменным какой-то зависимости.
    10) “switch” быстрее, чем “if … else if …” в большинстве случаев. Но я предпочитаю заменять switch на реализацию паттерна “стратегия”
    Стратегия то тут при чём? Да и вообще - внедрению зависимости при стратегии предшествует какое-то ветвление, так что без if … else, switch далеко не уедешь!

    Ну вроде всё.

    П.с.
    Автор, без обид, перепиши пост и удаляй тогда мой коммент нахрен, удачи в работе!
  • 07.10.2014 12:03:38 Max:
    Привет, Макс. Да конечно без обид. У каждого может быть свое мнение и свой стиль.
    Нет, переписывать не буду. И коммент твой удалять тоже.
    Ты наверное просто не понял меня.
    Я же не против микро-оптимизаций.
    Я просто показал, что экономить на спичках может встать себе дороже. И по прошествии стольких лет мое мнение так и не изменилось.

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