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

Поисковая оптимизация на PHP для профессионалов.
Руководство разработчика по SEO

Джейми Сирович, Кристиан Дари

LEOnidUKG, к сожалению, это касается вообще современного ПО, в массе. Производительность компьютеров выросла фантастически за последние годы. А как выросла производительность труда тех, кто использует эти машины? Пшик, да и только.

Вот какой-нибудь программист в 70-х годах умер бы от счастья, достанься ему современный компьютер в самой простейшей конфигурации. А мы ими, можно сказать, гвозди заколачиваем. Какое самое популярное использование? Игры, фильмы, интернет. Вот и всё.

P.S. А какие чудеса творили на Spectrum в 48-128 Кб(!)... Эх.

Какой код по вашему мнению более быстр/удобен/оптимален?

class site_funcs {

 var $cfg = array();



 function site_funcs () {

 global $config;

  $this->cfg = $config;

 }



 function fu1 () {

  return $this->cfg['option1'];

 }



 function fu2 () {

  if ($this->cfg['option2']) {

   return ($this->cfg['option2'] / 2);

  } else {

   return false;

  }

 }

}

или

 function fu1 () {

 global $config;

  return $config['option1'];

 }



 function fu2 () {

 global $config;

  if ($config['option2']) {

   return ($config['option2'] / 2);

  } else {

   return false;

  }

 }

Все же выдрано из контекста. Если скрипт небольшой и дальнейшее развитие не требуется - то пара функций. Если же объемы большие... да и вот тут у Вас глобальный конфиг встрял, когда куда лучше будет Singleton вставить :)

class site_funcs {

 var $cfg = array();



 function site_funcs () {

 global $config;

  $this->cfg = $config;

 }



 function fu1 () {

  return $this->cfg['option1'];

 }



 function fu2 () {

  if ($this->cfg['option2']) {

   return ($this->cfg['option2'] / 2);

  } else {

   return false;

  }

 }

}

 function fu1 () {

 global $config;

  return $config['option1'];

 }



 function fu2 () {

 global $config;

  if ($config['option2']) {

   return ($config['option2'] / 2);

  } else {

   return false;

  }

 }

1 вариант, только в класс лучше передавать конфик после его создания.

как-то редкто global используют в ООП

и

if ($this->cfg['option2']) {

должен быть по-правильному

if (isset($this->cfg['option2'])) {

или

if (empty($this->cfg['option2'])) {

кроме случаев когда $this->cfg['option2'] это true или false.

но это придирки.

тут даже if (isset($this->cfg['option2']) && is_numeric($this->cfg['option2'])) {

В камментах к упомянутой здесь статье на хабре был обозначен здравый список уровней оптимизации:

Я бы сюда добавил оптимизацию алгоритмов (т.е. на уровне метода), хотя очень часто по эффективности это те же блохи.

Так вот. Ясно, что FAQ про архитектуру составить невозможно, ибо всякая архитектура уникальна.

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

Оптимизация SQL-запросов: во-первых выходит за рамки, обозначенные заголовком, во-вторых (в нетривиальных случаях) - это большое шаманство, такого рода знания слабо поддаются структуризации.

Собственно, можно составить FAQ по ловле блох. Но я знаю несколько поводов этого не делать:

1. Он мало чем будет отличаться от той же переводной статьи с хабра.

2. Он спровоцирует холивар "красивый код VS быстрый код" или "время работы железа VS время работы программиста", или того страшнее "ф-ции VS ООП".

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

4. Блохи - они и есть блохи, незачем их обсуждать :)

На мой взгляд, было бы полезно:

1. Инициировать дискуссию по кэшированию.

2. Набросать материал по инструментам профилирования.

3. Набросать материал по настройке окружения.

P.S. Почистил ветку от флуда.

Все ваши варианты отвратительны до ужаса

(ни один программист такого не напишет)

Были бы более ясны условия, я бы предложил свой вариант, но...

Зингельшухер добавил 13.05.2008 в 03:07

Не редко, а вообще не используют никогда (это главный признак ламерства автора кода)

Ну, видимо задача в том, чтобы иметь конфиг-класс, глобально доступный.

Вот мой вариант, используемый на практике. Предполагается, что baseModule лежит мертвым грузом, а кассы типа concreteModule составляют большую часть рабочего кода. При этом может существовать конфиг-класс модуля, которому отдается больший приоритет.

class baseModule {
   function getConfigProp($prop_name) {
      // Если свойство не найдено, конфиг-класс кидает исключение;
      // Раньше я неплохо жил с return null; но исключения идеологически правильнее,
      // т.к. null тоже может быть значением.
      // Исключения глобального конфига перехватываются не в самом модуле, а сильно выше.
      try {
         // Пытаемся найти свойство в конфиге модуля
         return $this->getModuleConfigProp($prop_name);
      } catch (unknownConfigPropException $e) {
         // Если не получилось, ищем в глобальном конфиге
         $globalConfig = Config::getInstance(); // типо Синглетон
         return $globalConfig->getProp($prop_name);
      }
   }
   function getModuleConfigProp($prop_name) {
      $modConfig = $this->getModuleConfig(); // откуда берется конфиг модуля - дело частное, опустим
      return $modConfig->getProp($prop_name);
   }
}

class concreteModule extends baseModule {
   function foo() {
       // поскольку в рабочем коде модулей к конфигу приходится обращаться часто,
       // отдаем всю логику работы с конфигом родительскому классу.
       $cfg_var = $this->getConfigProp('my_prop');
   }
}

Если кратко. Для хранения глобального конфига юзаем паттерн Синглетон. Еще можно тупо хранить данные в статических переменных, и юзать статический же Config::getProp($prop_name) - кому как нравится, Синглетон пафоснее :) Если речь идет о регулярных модулях системы, полезно наследовать их от некого базового класса, который хранит логику работы с конфигом. В данном примере это позволило бы добавить поиск значения в собственном конфиге модуля, не трогая тело модулей.

Эксепшны юзать по вкусу.

P.S. Кстати, это не имеет никакого отношения к оптимизации, просто так удобней :)

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

P.S.: не пугайтесь кода, я писал его с телефона и не делал какого-либо функционала, просто привел аналогию одних функций в разном исполнении.

Нифига не понял. На PHP Вы пишете понятней, чем на русском :)