Постилка: 2009

Несколько недель назад у меня появилась задача сделать архив новостей для Drupal 6.x. Базой я выбрал модуль Archive. Продукт неплохой, но не совсем, то что мне нужно было. В результате, я сделал свой модуль, более простой и с AJAX (по требованию заказчика). Но сейчас не об этом.

При работе с Archive, у меня появилась такая проблема: на интернет-хосте пропала функция cal_days_in_month(), хотя на localhost'e было все ок.

Что бы функция заработала, нужно ее написать, правильно? :)

1. Открываем archive/archive.module
2. Вставляем функцию:

// the entire month into the block.
$prev_month = $month==1?12:$month-1;
$prev_year = $month==1?$year-1:$year;
+ //some old php versions don't have cal_days_in_month(), this code accounts for that
+ if(!function_exists('cal_days_in_month')){
+ function cal_days_in_month($calendar,$month, $year)
+ {
+ // $calendar just gets ignored, assume gregorian
+ // calculate number of days in a month
+ return $month == 2 ? ($year % 4 ? 28 : ($year % 100 ? 29 : ($year % 400 ? 28 : 29))) : (($month - 1) % 7 % 2 ? 30 : 31);
+ } 
+ }
$num_days_prev = cal_days_in_month(CAL_GREGORIAN, $month-1, $year);
$next_month = $month==12?1:$month+1;
$next_year = $month==12?$year+1:$year;

Плюсиками я обозначил код, который мы вставляем. enjoy ;)

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

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

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

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

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

Вызов метода объекта быстрее вызова “__call” , но в момент написания кода мы не всегда знаем какой метод и какого объекта будет вызван
Вызов статического метода быстрее чем вызов метода объекта, а как же ООП, инкапсуляция, коллекции, итераторы и т.д. ? Без них можно разрабатывать, но гораздо дороже!
Вызов функции быстрее вызова статического метода, конечно, но только в том случае, если вы не знакомы с ООП. Тогда ваша разработка стоит для конечного заказчика гораздо дороже, а поддерживать код становится гораздо сложнее
Доступ к локальной переменной быстрее доступа к глобальной переменной – действительно так, да и не нужно выводить из локального контекста переменную, если в этом нет необходимости
Доступ к глобальной переменной быстрее доступа к свойству объекта, но глобальные переменные – зло!!!
Прямой доступ к свойству объекта быстрее чем вызов магических “__get” и “__set” , естественно, но во время написания кода мы иногда не знаем какие свойства будет хранить объект.
Доступ к инициализированной переменной быстрее доступа к неинициализированной. Да, это так! И рекомендую инициализировать все переменные – это хорошая практика предупреждения возникновения неожиданных ошибок.
Абсолютные пути в “include” и “require” быстрее относительных
Объединение нескольких скриптов в один быстрее, чем несколько include. Да! Но разобраться потом в одном огромном файле…. И еще: если каким-то скриптам нужны почти все классы библиотеки – это будет плюсом. Другим скриптам нужен только один вспомогательный класс – в этом случае скрипт будет дольше стартовать, чем исполняться, к тому же мы получим беспричинный расход памяти.
“switch” быстрее, чем “if … else if …” в большинстве случаев.Но я предпочитаю заменять switch на реализацию паттерна “стратегия”
Не используйте регулярные выражения для простых операций со строками
Избегайте @ (оператор подавления сообщений об ошибках)
Избегайте выбросов Notice и Warning в ваших скриптах
Избегайте неиспользуемых переменых и неиспользуемых параметров методов
Добавление параметра в метод увеличивает время вызова,однако без параметров никуда.
Добавление к параметру метода type hint увеличивает время вызова, но уменьшает время разработки, благодаря повышению читабельности кода, а так же уменьшает возможность возникновения трудно-обнаруживаемых ошибок.
Вызывайте unset для переменных, содержащих большое количество данных или циклические ссылки
$_SERVER['REQUEST_TIME'] включает время старта скрипта
Кэшируйте вывод скрипта или результаты жадных на ресурсы функций
“echo” быстрее, чем “print”
“echo” поддерживает несколько аргументов, используйте это вместо конкактенации
“ob_start()” и “ob_end_clean()” могут быть лучше чем конкактенация
Строки в одинарных кавычках (’…’) обрабатываются быстрее строк в двойных кавычках (”…”), т.к. в первом случае не производится интепретация переменных внутри кавычек.
pre-increment (++$i) быстрее, чем post-increment ($i++)
“isset” быстрее, чем “array_key_exists”
Массивы быстрее классов с несколькими полями. Так что если вы используете классы только для хранения данных (такое я наблюдал в drupal) – замените их массивами.
“foreach” лучше, чем “for” в большинстве случаев
Открывайте ресурсы (файлы, БД, сокеты) непосредственно перед их использованием, освобождайте (закрывайте) их сразу, как только они становятся не нужны
Не доставайте из таблиц БД поля, которые вы не будете использовать
Используйте prepared database statements ( я затруднился перевести эту фразу, хотя и понимаю смысл)
Объединяйте несколько запросов в один, если СУБД поддерживает такой подход

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

Постилка

среда, 18 ноября 2009 г.

Определение скорости работы php-скрипта

четверг, 5 ноября 2009 г.

Fatal error: Call to undefined function: cal_days_in_month() и как с этим бороться

Полезные ссылки для Zend Framework

воскресенье, 1 ноября 2009 г.

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

z-index jquery fix

Первая запись

Я социальцый

Полезные ссылки

Архив блога

Обо мне