Pull to refresh

Comments 201

объясните почему не рекомендуют использовать __autoload. Это же очень удобно и спасает от исползования requece_once. А так список очень полезен. В закладки однозначно (они есть не просят :))
дополню вопрос: а если регистрировать автолоадер через spl, будет ли потеря скорости? у меня не наблюдается, профайлер показывает что это не является чем-то существенным.
UFO just landed and posted this here
Проще говоря, ООП во многих ситуациях приносит вред, усложняет разработку и замедляет выполнение кода.
А можно привести пример хотя бы одной ситуации такой?
Наверное, ООП не умеют пользоваться. Это действительно нередко.
ООП не ради ООП делается, а ради эффективности. Не умеешь писать _хороший_ ООП-код — лучше не пиши.
Я вот на Pascal за несколько лет не научился, и на php не пробую )
Ну а про медленность явно сказано. В 2-3 раза это немало.
Мы не берем людей, которые считают что ооп - это класс-неймпспейс со своими функциями и переменными. Это отдельная тема для разговора.

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

А насчет медленности - опять же, не факт. К примеру я использую в качестве шаблонизатора XSLT, я думаю не стоит говорить, что именно это самое ресурсоемкое место, по сравнению с которым вытаскивание и взаимодействие 20 классов (не считая таких ресурсоемких операций как работа с бд в адаптере для бд) - это как замена использования $array[key] на $array['key'].

А удобство от этих 20 классов неоспоримое, потому как мне больше никогда не приходится думать о том, как же изъебнуца что бы впихнуть в существующий функционал что-то такое новое, или исправить поведение некоторых вещей..
Вот в том-то и дело, что много месяцев. Именно этого пока и нет.
Тем более, у меня как-то все больше на javascript писать приходится, а там ООП немного специфический.
> ООП замедляет код всегда. И многое из того что было сказано в статье тоже.

Другое дело что можно весь проект написать в виде одного лишь index.php с низкоурвневыми функциями типа mysql_*

А ещё лучше написать все через модуль Apache на C.

Это я всё к тому что бессмысленно жертвовать качеством кода и удобством его сопровождения ради быстродействия. Прикупить железа будет проще. А вот если есть возможность повысить производительность приложения без ущерба - тогда и только тогда стоит пользоваться советами этой статьи. А так, конечно тот же __autoload очень удобен.
От использования require_once __autoload не спасает. Он спасает от ручного прописывания их.
Мне кажется, здесь важнее не задержка из-за использования функции автозагрузки, а потеря явного контроля над подключаемыми файлами. Хотя и здесь можно поспорить
я думаю, тут имеется в виду, что лучше иметь класс в самом скрипте, чем подгружать его с помощью __autoload. Естественно, это далеко не всегда удобно.
Ну нет, на такое я не пойду :)
объясните почему не рекомендуют использовать __autoload


Note: Exceptions thrown in __autoload function cannot be caught in the catch block and results in a fatal error.
не раскажете чем плох requece_once ?
1. Константа всегда работает быстрее (имеется в виду случай, когда ты знаешь заранее какие классы тебе нужно подключить). Функция __autoload написана для ленивых - взял себе указал директорию со всеми классами, она тебе все и определила.
2. Но для того чтоб выполнить свое назначение, ей приходится при каждом создании объекта проверять загружена ли в память ссылка на кэш или на файл класса.
3. Мы конечно же можем создавать малое количество объектов на один вызов скрипта, но как быть со статическими методами, которые при правильном программировании используется больше чем создание объекта, ведь __autoload проверяет загружен ли тот класс методов который используется при вызове метода.

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

На счет закладок ты полностью прав - это может послужить хорошим списком правил для начинающих в программировании. Автору и переводчику спасибо!
UFO just landed and posted this here
косяк перевода. Надо так:
Скорость вызова метода, судя по всему, не зависит…
Спасибо, исправлено :)
>> Было: if (strlen($foo) > Стало: if (!isset($foo{5})) { echo "Foo is too short"; }

в топку такие советы. Сэкономленная наносекунда не покроет расходов времени на формирование мимики на лице программиста, получившего такой код в поддержку
>> Не всё должно быть ООП, часто это излишне, поскольку каждый метод и объект занимает много памяти.

туда же ... не все должно быть ООП, но вовсе не по этой причине
Назовите свою причину :)
Я не готов описать это в одном сообщение. Если кратко: ООП следует применять исходя из принципов создания четкой и гибкой структуры приложения, что вовсе не означает необходимость инкапсуляциии всего в классы
Это называется "красивый код". Зачем перерасход ресурсов, даже минимальный, если можно заставить код работать быстрее?

Не вижу в этом коде ничего сложного для понимания программистом. Если программер не может разобраться в этом коде, то нечего ему делать в этом проекте.
следует заметить, что {} это депрекатед конструкция
используя рекомендуемые [] можно натолкнуться на очень неоднозначный код
Или на очень не однозначный пост…
Если по вашему мнению {} — депрекатед (что не правда), то почему можно натолкнутся на неоднозначный код используя рекомендуемые (что опять не правда) «[]» ???
По поводу правды и неправды.
В мануале написано так: "However, using square array-brackets is preferred because the {braces} style is deprecated as of PHP 6"
спасибо, не успел я чуток :-)
Странно, в книге «PHP 5 профессиональное программирование», отмечается что {} появились в PHP 5, и что их использование рекомендуется. Кроме того на хабре помнится советовали использовать именно их из-за скорости. А в PHP 6 уже deprecated.
Я тоже недавно наткнулся на это в этой же книжке, тоже был весьма удивлён.
В PHP 4, наоборот, объявили устаревшими квадратные скобки и ввели взамен фигурные. Теперь в обратку пошли.

До выхода PHP 6 устаревшими являются квадратные, а не фигурные скобки.
неоднозначный в том смысле, что при слабой типизации пхп, ты не сможешь сказать - чем является переменная, массивом или строкой, и код $var[$index] вполне может быть истолкова и так и так.

>> что опять не правда
http://ru2.php.net/manual/ru/language.ty… ("Доступ к символу в строке и его изменение")
В случае, когда вместо строки переменная будет массивом.
логическая цепочка мыслей, которая формируется, когда программист видит конструкцию strlen($foo) <5 меньше , чем когда он видит !isset($foo{5}) .
А можно ещё каждую строку словами комментировать, чтобы уж совсем просто было.
лучше писать так, чтобы не приходилось комментировать :-)
Это я к тому, что не следует слепо гнаться за простотой. Если программист опытный, то для него такой код не составит труда.
опытный программист может разобраться в коде любого качества за соответствующую оплату
из этого не следует, что так делать нужно
Не следует гнаться за микросекундами в ущерб простоте. Данный пример считаю употребимым только в очень узком месте при огромных нагрузках.
Вы параллельно с написанием кода еще и его обфускацией занимаетесь? Не лучше ли оптимизировать БД, файловую систему, или добавить еще пару мегабайт памяти, чем гоняться за каждым тактом процессора?
Если твой код выполняется 5 миллионов раз, а ты можешь съэкономить в коде чуть-чуть время (пускай даже 5% от его времени выполнения) то это может окозаться очень даже веским критерием.

Опять же, прежде чем заниматься таким, надо брать в руки профайлер и доказывать что это *НУЖНО* делать.
Не надо рубить с плеча...
У каждого програмиста свой стиль и своя "специализация".
Кто-то силен в архитектуре, кто-то в "факторинге" кода.
Так вот "архитектор" может такую конструкцию при быстром просмотре кода и "просмотреть"... и потратить лишнее время.
а секономленая наносекунда... особенно при нынешней производительности серверов... и качественных "систем" кеширования становится бесполезной.
Вот если бы это был стиль "по умолчанию" (расписанный во всех учебниках и "практически" применяемый во многих языках!) - тогда другое дело, а так... сомнительное "ускорение". А учитывая что нормальный програмер знает не один только php и как минимум в день програмирует на разных языках... к концу рабочего дня могут быть и косяки. А это гараздо хуже
А я поддерживаю автора в этом плане. Подобная конструкция не намного сложнее, она понятна и прозрачна (для меня — да). Кроме того, из неё можно сделать традицию, как это было со многими код-куками.

А если говорить об экономии времени, то надо сравнивать не скорости интерпретации страницы компом или кода программистом, а их порядок, т. е. порядок программистов и порядок пользователей продукта. Если у продукта десять проггеров и десять пользователей, то конечно стоит отдавать предпочтение «привычному» коду )
Большинство приемов даст мизерный прирост производительности. Настолько мизерный, что часто не имеет смысла вообще тратить на это время. Лучше за это время подумать над каким-нибудь запросом к БД или об общей архитектуре приложения. А print-->echo, "-->' — это фигня.
Все мизерное при определенной нагрузке становится существенным.
Возможно это и не касается '->", print->echo, а вот preg_replace -> strtr - явно...
Ну и конечно главное внимание стоит уделать БД и работой с ней..а потом уже такие методы.
Вот именно что при определенной нагрузке, которая, кстати сказать, должна быть довольно большой (если конечно архитектура нормальная). Да и опять же, профайлер в этой ситуации в помощь и оптимизация различных алгоритмов...
Здесь я согласен, верная архитектура гораздо важнее. Однако мне, как поклоннику красивого кода, было исключительно интересно ознакомиться с этим списком.
И что же в этом списке относится к красивому коду? Замена очевидного кода на неочивидный?
Замена быстрого кода на чуть более быстрый. Выигрыш минимальный, но он есть.
есть большая разница между красивым кодом и оптимизированным.
Первый легок для понимания и сам показывает ошибки (Пример: if(0=i))
Второй бывает нужен в узких местах, но точно не для повседневного использования. Слишком велики затраты на вникание в код каждого нового программиста.
з.ы.
Я люблю именно красивый код, но последнее время занимаюсь оптимизацией.
Гммм) melk, возможно, Вы имели ввиду... if(0==i) ??? А то как то Ваш пример не похож на "именно красивый код")))
да нет. как раз if (0 =$i)
ибо в такой ситуации компилятор обругает за попытку присвоения константе, при этом вариант if ($i = 0) остается вполне легальным, хотя и сделает не совсем то что обычно требуется (==)
я сам ошибся... я имел ввиду if(0==$i)... а ваш пример работать все равно не будет... вам нужно сравнивать, а вы присваеваете.
всё! спать! :D

да! у Вас всё было правильно!
Гммм) melk, возможно, Вы имели ввиду... if(0==i) ???

но я еще толком не проснулся и прочитал Ваш вариант с точностью до наоборот, т.е. обычный вариант когда переменная слева а константа справа.
и сунулся объяснять почему «константа слева» приятнее.
а на счет того что мой пример не сработает, дык в том-то и фокус (типа для иллюстрации).


и только после вашего комментария («я сам ошибся... я имел ввиду if(0==$i)...»), когда начал смотреть где ошибка, я понял что писал спросонья и неправильно Вас понял :")

приношу извинения.
Пункты 3 и 29 - вообще одно и тоже ... автору списка - дизреспект
15 и 42 - тоже, причем, если мне не изменяет память, как раз mod_deflate сжимает на лету, в то время как mod_gzip делает сжатие через временный файл.
Это разные вещи, и применять их следует в разных ситуациях. Поэтому и упоминаются оба.
Вот почему они в разных пунктах, и тем более в разных концах списка - для меня остаётся загадкой :)
Ну да, в разных ситуациях. mod_deflate — стандартный модуль apache 2.x, а mod_gzip — внешний модуль для apache 1.x.
Я тоже заметил :)
Но перевод - есть перевод, убирать пункт я не стал.
Да и "Повторение - мать учения" :)
Спасибо! Пригодится.

P.S.: Следовало бы разделить этот список на разделы, а так все перемешано.
Совет 44-й: заюзайте профайлинг и начните выполнять оптимизацию в тех местах, где она действительно необходима
Простите за ламерский вопрос, "Профайлинг" - это что ?
За 33-й пункт убил бы (не дай бог так начнут писать). А вообще, задал бы автору вопрос: вы особираетесь бороться за написание самого оптимизированного скрипта в мире, или решаете задачи эффективного программирования (отношение [затраченные деньги==затраченное время]/результат). Прироста в 2 раза можно добиться и путем покупки сервера в 2 раза мощнее. Про кеширование надо помнить, это да. Остальное даст малый прирост, но лишней возьни с этим будет много. 17 — а что, так еще кто-то пишет? О_о
если следовать указанным советам, можно ускорить работу скрипта вкупе на 1% и получить отличный неподдерживаемый говнокод
ура, товарищи
Боюсь, что и процента не получится. Чаще сервер втыкает в канал, память и базу. А скрипты сами по себе не так уж часто тормозят. Смысл ускорять код, если например у пользователя медленный интернет и он будет эту страницу качать несколько секунд?
я надеюсь это был риторический вопрос? :-)
Это был вообще не вопрос :-) просто такой синтаксис :-)
> Закрывайте свои соединения с БД, когда закончите работать с ними.
В этом есть какой-то тайный смысл o_0' ? После выполнения скрипта соединение же закроется само...
точно такой же как и в высвобождении памяти, при условии что её хватает на нормальную работу скрипта
смысл в том, что при высокой нагрузке(большом количестве запросов к странице которая неадекватно использует память), может банально нехватать памяти сервера, что будет приводить к общим тормозам.
Для большого количества запросов существует кеширование (пункт, кстати, 31-й), банальная оптимизация запросов и увеличение мощностей сервера, как уже писали выше.
чем закрытие соединения экономит память? неужели накладные расходы на хранение хандлера так высоки? не верю
извиняюсь - ошибся комментом. это я про освобождение памяти
не сталкивался ни разу с явлением
скрипты всегда вполне помещаются в 16мб, и почти всегда в 8мб
к тому же неизвестно ещё как будет в этом случае действовать сборщик мусора в пхп
"битрикс. управление сайтом" минимальное требование оперативки - 32М. Это нормально? Вот для таких и нужна эта статья.

И вообще всегда будет работать принцип: создал - уничтожь, открыл - закрой, и тп. А то, что PHP за нас делает половину работы, за это мы расплачиваемся производительностью и безопасностью.
нет, не нормально
но программистам битрикса эти советы не помогут...
WordPress 2.5 тоже, кстати, 32 метра просит
У же несколько раз встречал в сети эти советы, но на аглицком. Каждый раз они провоцируют бурное обсуждение... Многие советы спорные или являются "экономией на спичках". Выигрыш от них будет ничтожно мал в сравнении, например, со временем обращения к БД и временем работы не оптимального алгоритма.

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

Про строки в двойных и одинарных кавычках:
разница может и есть, но только при разборе скрипта и сводится к нули при использовании кешера байткода. Специально в цикле делал eval строки в одних и других кавычках, на миллионе итераций особой разницы не заметил. Согласен, что $a['key'] логичнее $a["key"], но в подобном случае

$s = "<tr>".
"<td>$Key".
"<td>$Value".
"</tr>\n";

лично мне удобнее использовать одинаковые кавычки, независимо от того, есть в строке переменные или нет (но так и не смог убедить в этом шефа...)

Гораздо более впечатляющего результата можно достичь оптимизацией SQL-запросов, алгоритмов или структуры приложения.

P.S.
В который раз не могу понять как 42-й пункт соотносится с оптимизацией PHP-кода.
во-первых, упоминалось $a[key] (без кавычек) (в мануале описано, почему так не надо делать)
во-вторых, использовать одинаковые кавычки можно и так $s = "text{$a["key"]}"
$a[key] такое же зло, как Register Globals + Magic Quotes. А что если константа key определена через define ?
кто спорит?
я лишь отвечал на пост об одинаковых кавычках...
Сказанное про кавычки, относилось к п. 23. о замене двойных кавычек на одинарные везде, где это возможно.
Люблю оптимизировать все и вся, даже если эффект мизерный. Уже встречал совет 3 и даже пытался писать так - зачастую жутко неудобно. Решил провести тест и, хоть убейте, не вижу преимущества вывода через запятую - он медленнее в большинстве случаев на порядок.
Покажите мне реальные результаты, на основании которых даются такие советы.
';

$start = microtime(true);

ob_start();
for ($i = 0; $i ';
Спасибо, теперь понятно, почему мои тесты показывали другие результаты - если убрать буферизацию, то получим бОльшие тормоза за счет бОльшего числа i/o обращений:

<?php

$string = 'foobar';
$s1 = 'echo '.str_repeat('$string,',30).'$string;';
$s2 = 'echo '.str_repeat('$string.',30).'$string;';

$start = microtime(true);
eval($s1);
$end1 = microtime(true) - $start;

$start = microtime(true);
eval($s2);
$end2 = microtime(true) - $start;

echo "\n".$end1;
echo "\n".$end2;
?>


Хотя в вашем примере через запятую все равно будет быстрее, но это специфика примера.
P.S. Кто-кто, а парсер тут точно не лох :))
>> Хотя в вашем примере через запятую все равно будет быстрее
читд

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

30-й совет по оптимизации PHP улыбнул - не использовать PHP :)

33-й совет работает только если у вас однобайтные строки, весь мир уже давно на utf8 перелез, а в PHP (до сих пор) utf8 нативно не держится - только через расширения для поддержки мультибайтных строк, типа mb_string... Соответственно, надо юзать стандартный strlen, потому что php-кодер не должен полагаться на однобайтные символы, мало ли, может, админ включил mbstring.func_overload (особенно актуально для тех, кто пользуется сторонним хостингом)...

Получается, что все перечисленные советы для "начинающих", т.к. "продолжающие" и сами знают, где и как чего оптимизировать у себя. А "начинающие" вообще не должны заниматься оптимизацией - вредно для психики. Premature optimization is the root of all evil.
Дальше 17 пункта читать не стал.
UFO just landed and posted this here
UFO just landed and posted this here
Советы очень неплохие,
насчет этого не уверен тоже
# Методы в производных классах работают быстрее, чем они же, определённые в базовом классе.

А так все супер, а насчет ООП - какой смысл делать ОО например скрипт который забирает тИЦ с Яндекса? Вещь одноразовая - написал и забыл, ООП хорошо использовать в больших проектах, для маленьких скриптов это просто глупо будет и все, достаточно модульного подхода (время паскаля еще не прошло) =)
почти наверняка этот скрипт будет работать также в паре со скриптом, который "забирает" PR гугла, наличие в DMOZ или ище где
почти наверняка у этих классов общими будут 90% кода. почему бы не вынести? :-)
при этом получить хороший (переносимый) код :-)
А нельзя сделать это функциями? И в них заложить 90% кода? Вот в С++ мне ООП очень нравиться, и я вижу смысл его использовать, в PHP уж простите в 90% лично мне хватает модульного подхода, ну ненравиться мне реализация ООП в нем.
90% кода общего (абстрактный класс), 10% частного - наследники
ляпота? :-)

>> ну ненравиться мне реализация ООП в нем.
конкретики требуют рабочие классы! :-)
ООП применяется для организации очень сложных проектов - если его применять к простым поектам (это подавляющее большинство Web-проектов) ничего, кроме того, что простой проект превратиться в сложный не произойдёт. Применяются эти конструкции в очень сложных проектах, когда от базового класса до конечного - 10 иерархий наследования, т.е. 10 уровней абстракций

кварк
ядро
атом
молекула
супермолекула
фермент
клетка
орган
организм
социальная группа

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

ООП в PHP - это копия объектно-ориентированной модели Java, он просто скопирован и всё, а сам язык во многом копирует Perl - а это противоречивые технологии. ООП введён для снижения сложности монолитных графических программ и библиотек, а Perl и PHP для снижения сложности CLI-интерфесных прогрмм (интерфейс командной строки). UNIX и ООП - это несовестимые вещи, первый преследует разделеление сложности на уровне мелких взаимодействующих программ, каждая из которых выполняет свои цели, а второй разделение монолитных программ и библиотек, больше характерных для графического интерфейса, принятого в среде Windows и Macintosh.

Я могу привести 1000 примеров удачного применения ООП в Windows, но почти ни одного в PHP-программировании - философия разная...
огромный пост, и ни слова в ответ "что не так в реализации объектной модели в пхп"
Одна из серьезных проблем ООП в PHP 5 уже была озвучена. Это отсутствие модификатора наследования.

Отсутствие возможности множественного наследования.

Конструктор базового класса не вызывается по умолчанию из конструктора наследника.

Следствием отсутствия строгой типизации является отсутствие возможности перегрузки функций.

В PHP 5 есть возможность указать тип аргумента функции (только для классов и массивов). Если переданный аргумент не будет соответствовать требуемому типу, возникнет ошибка и функция вызвана не будет.

Отсутствие нормального определения виртуальных свойств и методов класса (свойств, которые имеют геттеры и сеттеры).


Открытость классов.

Смешение статических и нестатических методов и свойств.

Объектно-ориентированные языки поддерживают создание структур с большим количеством связующего кода и сложными уровнями. Это может оказаться полезным в случае, если предметная область является действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому, что им известны эти способы и они умеют ими пользоваться.
Эрик. С. Реймонд. Искусство программирования для UNIX.
> Отсутствие возможности множественного наследования.
интерфейсы в этом плане более привлекательны.
а по поводу "ооп в ос", хрестоматийнее вспоминать beos/haiku
UFO just landed and posted this here
Читайте внимательно пост там обьясняется почему в UNIX ООП не распространет, почитайте Эрик. С. Реймонд. Искусство программирования для UNIX там об этом тоже говориться, покажите реально удачный пример применения ООП в PHP, и воздержитесь пожалуйста от мата, очень не красиво получается.
Практически любой фреймворк? Обратный пример — Drupal — говно еще то…
UFO just landed and posted this here
Вы не совсем верно уловили суть совета.
Рекомендуется не отказываться от ООП, а не совать его везде, где его можно применить.
у меня точка зрения на вопрос доведена до крайности - если код будет в принципе поддерживаться и развиваться дальше, он обязательно должен быть написан в соответствии с ОО парадигмой
Насчёт вас я не могу уверенно судить, но про многих быдлокодеров скажу - им следует всегда использовать функциональное программирование, иначе их код становится ужасен.
s/функциональное/процедурное/ :)
UFO just landed and posted this here
Поясните столь резкое утверждение.
UFO just landed and posted this here
Я так понимаю, ответ на мой вопрос "Нет таких задач, в которых без ООП - лучше".
Элементарный пример - гостевая книга. Можно написать с ООП, постепенно превращая в монстра. А можно использовать функции и получить более быстрый и простой код, не запутывая эту простоту.
Одна из основ РНР - простота использования. ООП усложняет эту простоту.

P.S. В будущем если хотите получить чёткий ответ - выражайтесь яснее. "Вы разве не понимаете, что это чушь?" и "Вы какую задачу решать собрались?" - не являются ясными высказываниями.
Человек ксати еще привык решать задачи так, как он давно уже привык. Поэтому если человек в поседневной жизни использует ооп механизмы то, даже простейшие задачи он будет решать с помощью объектов и их взаимоотношений.

Это не плохо. Это просто другой подход, для которых он подходит идеально, а для других - как что-то такое тяжелое и многовесное, непонятное и вообще ненужное.

К примеру я тоже бы даже самую простейшую задачу решил с помощью ооп, ибо для меняэ то проще, я не люблю писать по много раз один и тот же код, который делает одни и те же вещи. А как показала моя практика, в очень многих задачах есть очень много мест где код просто напросто дублируется. Практически полностью...
UFO just landed and posted this here
Я придерживаюсь правила, что надо писать логически понятный и красивый код, который асимптотически работает быстро. Извращаться с нетривиальными и deprecated- конструкциями ради лишней микросекунды - удел горе-оптимизаторов. Хочешь скорости - пиши на C.
Ладно тебе =) люди, вон, и на 10-ые модели лады «спортивные» рули ставят =) Не каждый может себе позволить sti или программирование на c.
32 — вообще не имеет отношения к php, но достаточно грамотно при общем подходе.
1,35 — алилуя! Дяденька бог, сделай, пожалуйста, так, чтобы объектная модель в php сдохла, а статические классы выжили.
3,33 — не знал, интересно!

Автору спасибо,
str_replace быстрее, чем preg_replace, но strtr быстрее, чем str_replace.
ИМХО нужно подкорректировать это высказывание:
но strtr быстрее, чем str_replace в цикле по массиву замен, но str_replace($arWhat, $arReplace, $string); быстрее чем strtr($string, $replaces).

http://ru2.php.net/manual/ru/function.strtr.php#52493
пункт 30 меня вообще сразил наповал...
всё это - гонка за 0.1-0.2 секунды... так ли это важно?
вообще-то оптимизация в 0.1с это очень приличная оптимизация :-)
советы нацелены на экономию скорее 0.001с
Объясните, "" медленнее, чем ''. Но '1 ' . $v . ' 2' медленнее, чем "1 $v 2", т.е. в первом случае конкатинация, а во втором просто лишний jump в StateMachine(лексический анализатор)
Да и имхо вообще простая оптимизация SQL-запросов увеличит производительность поболее, чем все эти советы.
Всецело поддерживаю!
Вы даете советы и говорите что echo работает быстрее print или require_once дорого обходится, а тесы вы проводили? Почему вы решили что дольше? Меня интерисует больше доказательство этого, чем просто бла-бла-бла )
Придётся продублировать коммент по-английски :)
Я текст лишь переводил, так как мне он показался заслуживающим внимания. Судя по количеству комментариев, он действительно такой - многих программистов заставил задуматься и поразмышлять.

А ссылка не первоисточник есть в статье.
Ага, а первоисточник 2005 года ) Сейчас все выглядит несколько иначе в плане производительности ) Давайте еще откопаем источник 2000 года и посмотрим как там все было
21, 24 - уже маразм, глобальные переменные уже сами по себе зло, люди уже давно придумали конструкторы\параметры функций\делегирование и т.д. и т.п. и возвращение результата.

37, 38 - наверно автор не читал Мартина Фаулера ....
21, 24 - это сравнение скорости работы, выводы делать читателям.
И вообще, такая оптимизация ничего не дает на самом деле даже на высоконагруженных проектах. Потому что в этом случае производительность пхп особой роли не играет, всегда можно сделать балансировку на нескольких бэкэндах. Да и кэширование даст куда больший выигрыш.
Главное, не писать откровенно корявый код, подвешивающий сервак даже на простых проектах. Видел я сайт одного провинциального автосалона (ясно, что посетилово у него никакое), так вот, некоторые страницы у него открывались по 30-40 секунд. Посмотрел код страницы, а там разработчики в конце комментом зафигачили время генерации страницы и количество запросов. Так вот, время генерации у них и было 30-40 секунд, а количество запросов - более 2000. Ладно еще кеш был, живущий одну минуту (хотя на странице за это время ничего не меняется).
:-D
Ссылку не дадите?
подобная оптимизация скорее хороший тон, нежели гонка за сокращением машинного времени. Да и потом, liveinternet.ru, самая крупная система статистики в рунете, стоит на одном сервере, на одном. Конечно, можно рассуждать как вы, мол какие проблемы, воткнуть несколько бэкендов и все дела, а можно пооптимизировать все подряд и экономить. Между 3-х литровым атмосферником и 1.8 турбиной я выберу турбину. Мощность та же, а вот экономия больше.
Да и потом, оптимизация бэкенда хотя бы на 0,01 секунды за сессию на высоконагруженных сервисах это огромный плюс.
Если вы, грубо говоря, получаете с проекта миллион долларов, то не пофиг ли, сколько вы будете тратить на серверы - тыщу, две, три, пять?
Я и говорю, что надо писать красиво, а вот такие конструкции if (!isset($foo{5})) - это и есть гонка за машинным временем в ущерб читабельности и красивости кода.
P.S. Я знаю, что есть разные взгляды на понятие "красота кода". :)
по поводу isset полностью согласен. Однако интересное решение =)
Получи сначала с помощью 90% этих советов 0,01 секунды на сессию, умник.
А потом убедись, что грамотное кэширование делает ненужным практически весь этот список.
выключи логирование ошибок, откажись от объектов, перейдя на статические классы — это уже даст не малый прирост производительности, если проект действительно высоконагруженный и это не «домашний» сайтик.
Видал код таких вот людей, которые готовы полностью все делать через мемкеш, мемкеш сервер упал и такой код валит сервак за секунды. Кеш это замечательно, но не панацея. Веб — отличная площадка для практики хорошего, быстрого кода за малые деньги. Ведь практически любое прикладное программирование не требует быстрой работы софта, тем более что чаще софт работает с одной сессией на мощной тачке. Зачем же губить эту площадку говнокодом с грамотным кешем?
Не надо нести ерунду. про каких-то там людей, у которых все падает.
мемкеш - не синоним слова кэширование.
Я написал две простые вещи
1. Любой высоконагруженный проект использует кэширование.
2. Кэширование сводит на нет 90% этих советов.
Вот и все. И не надо перевирать мои слова.

Да и без кэширования большая часть этих советов - редкостный идиотизм и никакого реального влияния на производительность не оказывает.

Писать echo "Вася $abcd".$efgc; - не говнокод.
А вот человек, который будет писать 'Вася ',$abcd,$efgc; рассуждая о повышении производительности - профнепригодный даун
знаете, Дональд Кнут как-то сказал:

Premature optimization is the root of all evil. Что значит "преждевременная оптимизация — корень всех зол".

В топку большинство этих советов.
Особенно порадовала ссылка на статью 2005 года в пункте 43)))))
UFO just landed and posted this here
UFO just landed and posted this here
Куча идиотов выключают в PHP.ini вывод нотисов и варнингов, и пишут код как попало. Им кажется, что все идеально. Но ошибки от этого не пропадают. Они пишутся в лог и занимают изрядное время на свою обработку.
По поводу древности статьи:
тех, кто свято верит подобным советам, не смущают даже такие ископаемые как статья 5-тилетней давности http://php.spb.ru/php/speed.html, которая справедлива в лучшем случае для PHP4. Частенько вижу как эту статью советуют в ответ на вопрос об оптимизации PHP-кода. печально...
UFO just landed and posted this here
"Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы."

Они сами мгновенно удаляются при выходе из области видимости.
> Они сами мгновенно удаляются при выходе из области видимости.
Не думаю что сборщик действует так неоптимально.
Да, именно поэтому не стоит удалять что-то, что не поддерживает соединения с удалёнными ресурсами или не занимает пулов БД - самостоятельно. Сборщик мусора - быстрей.
У глобальных пременных глобальная область видимости, и удалаются они только после выполнения всего скрипта.
Глобальная переменная для этого и делается, чтобы не удаляться.
А если удалять глобальные переменные - это абсурд.
пользуясь случаем, спрошу
как изучить PHP 5 за 24 часа?
#9 не рулит, ибо он без microseconds + мереет не только скорость php но и время реакции сервера на запрос. Лучше использовать microtime.

+ Стоило бы упомянуть о том что не надо использовать большие массивы, они адски едят память (пример 17000 эл-ов и по 15 вложенных) => 120мб.
Не так часто нужны микросекунды, №9 имхо один из наиболее адекватных советов
"мереет не только скорость php но и время реакции сервера на запрос"
Т.е. выполнение вашего кода в REQUEST_TIME (которое обычно и хочется замерить) будет лишь частью. Тогда уж лучше YSlow пользовать, он более точно время запроса отображает + учитывает весь контент (img, js, css).
2. - еще бы автор оригинальной статьи бы вспомнил о шаблонизаторах - которые тоже медленней, нативного PHP + HTML, кстати индусы об этом знают - то-то никто шаблонизаторы не использует.

17. - Это к PHP3 наверное относится?!? Если писать "неправильно" - то будет "Notice" о необъявленной константе...
Т.е. этот пункт можно скрестить с 18-м - пиши код так, чтобы не вызывать ошибки, включите отображение ошибок <?php error_reporting(E_ALL)) ?>, и следите за чистотой кода...

35. - Индусы постигли сей пункт...
:) познавательно и весело. пункт 30 в закладки, зачем PHP если есть HTML :)
За совет 10 - порву! Отдельно взятый strpos или substr может и быстрее preg_replace, но когда они складываются в уродские substr ($a, strpos ($a, "{"), strpos ($a, "}") - strpos ($a, "{")) - причем вложенность который возрастает в геометрической прогрессии в зависимости от того, строку какой сложности вы хотите разобрать - получаем проигрыш как в производительности так и в наглядности по сравнению в четким и ясным preg_match или preg_replace.
UFO just landed and posted this here
Некоторые советы очень плохие, это когда не ехать, а шашечки. Чем выигрывать 5-7% производительности, лучше писать хорошо поддерживаемый код. Сервера дешевеют, а вот программисты нет.

Если до такой степени гоняться за производительностью - лучше писать на C++
5-7% - это серьёзная оптимизация, на которую стоит затратить время и силы.
Бесспорно, хорошо поддерживаемый код - важнее :)

>Некоторые советы очень плохие
Но ведь некоторые - хорошие :) Значит мои усилия по переводу были не зря.
Да, некоторые хорошие, спасибо. (наверное с этого и надо было начинать)
5-7% - смотря какой ценой.

Иногда приходится слышать что-то типа:
- Zend Framework медленный, я его почикал - вырезал все комменты и в один файл засунул, получил 14% выигрыш в скорости. Правда, молодец я? :)
- А вы акселератор какой использовали?
- Да я... это... Ой, а чойто?
- Вы не молодец, вы батенька мудак :)
Ну еще думаю, что чем тратить кучу времени на массированную ловлю блох, лучше немного подрихтовать модель и засунуть в проект еще больше кеширования.

Самый быстрый код - это код, которого нет ^_^
Можно даже оформить всё в список. Уровни оптимизации:
1. Архитектура
2. Кеширование
3. SQL-запросы
4. Ловля блох :)
Ага, вот примерно так и есть.
Большинство из этих 43 советов как раз относятся к четвертому пункту :)

"Преждевременная оптимизация - корень всех зол" &copy Кнут
Чувак.
Не надо так настойчиво и безнадежно страдать из-за низкой самооценки и искать оправдания.
Ему говорят, что текст - мусор, а он в ответ - "божья роса!". "Не зря переводил!"
Говно ты перевел. Говно.
Пойми это уже, наконец, и успокойся.
Нету там никаких 5-7%. Там и 0,5-0,7 нету, даже без акселерации и кэширования.
Писал это мальчик-дурачок, твой ровесник. Надергал по интернету мусора.
Не надо все написанное в интернете на английском априори считать кладезью мудрости.
Вреда от этого собрания куда больше, чем пользы. Опять будут бегать толпы малолетних идиотов-оптимизаторов.
Собственно, от наличия таких "гуру" как вы толпы малолетних халтурщиков и имеются.
А можно поинтересоваться механизмом?
Ну, в общих чертах, как от таких гуру происходят толпы халтурщиков?
С интересом ознакомлюсь =)
> Ну, в общих чертах, как от таких гуру происходят толпы малолетних халтурщиков?

Об этом вам родители должны были рассказать ;)
чеж тут непонятного, мыши - из грязного белья, тараканы - из нечистот, халтурщики - от наличия гуру. просто же, ей богу.
Вы со мной не знакомы. Вы ни разу не видели меня, не общались со мной.
Всё, что вы знаете обо мне - это то, что я перевёл статью, которая не понравилась сообществу. Вы прочитали несколько моих высказываний о ней. Может быть, даже нашли в интернете что-нибудь обо мне.
Вы не знаете о моих умениях, а разговариваете со мной так, будто знакомы минимум неделю.

В следующий раз тщательно выбирайте выражения при общении со мной.

P.S. Если бы эта статья была глупой, она не вызвала бы такое обсуждение со стороны сообщества. Она заставила задуматься над оптимизацией кода и её смыслом десятки программистов, и это говорит мне о том, что я проделал свою работу не зря.
UFO just landed and posted this here
Судя по тому, что рейтинг как аффтара, так и его писулек, медленно но верно растет вверх, надежды явно не оправдались.

Лишний раз я убеждаюсь в том, что молчаливое большинство постетителей хабра - малолетние идиоты, неспособные понимать минимальную логику, с уровнем мышления обезьяны. обсуждение или не читают вовсе, или не поняли ни буквы. Как счастливый аффтар, который выискивает только положительные отзывы и с презрением отвергает отрицательные.
А вот про кавычки - вот это им доступно и понятно. поменял двойную на одинарную - и все начало летать.
Если у тебя есть фонтан, затни его, дай отдохнуть и фонтану.
© Козьма Прутков
UFO just landed and posted this here
Кстати, вот и о "мальчике-дурачке, моём ровеснике" по имени Reinhold Weber
Не вижу там ничего, что расходилось бы с моей характеристикой.
Впрочем спасибо, почитал ещё раз, повнимательнее
http://reinholdweber.com/?p=1%20union%20select%201,2,3,4,user(),6,7,8,9
Убедился, что он такой же дебил, как и ты.
Простите, что усомнился в ваших словах.
Пойду брошусь с обрыва, освобожу этот мир от дебила-себя! :)

Ещё раз убедился, что с вами бесполезно разговаривать. Ну что же, больше вы для меня не существуете.
Ты, похоже, настолько туп, что не понял смысла ссылки, которую я дал.
То есть, человек, который вообще ни бельмеса не смыслит в веб-программировании, берется что-то там переводить.
Хабр, все-таки - уебищный сайт. На любом другом ресурсе такого популяризатора затоптали бы в пыль. А здесь оно процветает. И даже что-то о себе мнит.
Совет номер 44: научитесь уже нормально работать со SQL :)
на счет 28-го пункта: что быстрее: '' или "".
'' обрабатывалось быстрее чем "" до версии 4.? (точно не помню)
после, это дело исправили.. теперь разницы нет (сам тестил).

33 пункт:
Было: if(strlen($foo)<5) {echo "Foo is too short";}
Стало: if(!isset($foo{5})) {echo "Foo is too short";}
может эта модификация и быстрее работает, но смысл написанного разный, и некоторые будут ломать голову, что же пытались тут проверить.

также, как уже говорилось ранее: пункты 3 и 29 одинаковы.

добавлю ещё: sizeof() будет быстрее, чем count(), при больших размерах массива.

Есть такая статья по оптимизации:
http://php.russofile.ru/ru/translate/unsort/optimizing/
В подразделе "Бесполезная оптимизация" говорится, что echo не быстрее print (это про пункт 2).
Также, в статье приводятся доказательства, пояснения и примеры.
добавлю ещё: sizeof() будет быстрее, чем count(), при больших размерах массива.

Читал про это на php.spb.ru, но той статье - сто лет уже.
Мануал по PHP говорит "sizeof — Alias of count()"
Да, возможно я там читал когда-то...
Прошу прощения за устаревшую информацию относительного этого.. поторопился..
Какой феерический маразм.

PS. Я невнимательно прочитал или там действительно не написано про двойные/одинарные кавычки?
Вы невнимательно прочитали
24. Объявление глобальной переменной, без использования её в функции, также замедляет работу (примерно на ту же величину, что и инкремент локальной переменной). Вероятно, PHP осуществляет проверку на существование переменной.

Какое объявление глобальной переменной в функции? "global $var"? Причём тут проверка? PHP вводит при этом локальную переменную, являющуюся ссылкой на глобальную. Ричард Вебер пишущий статьи по оптимизации в основах PHP не разбирается?

Инкремент неопределённой переменной в 9-10 раз медленнее, чем заранее инициализированной.

А предварительная инициализация переменной и её инкремент, как соотносится с инкрементом неопределенной?
Оптимизация на ранних стадиях. Докатились.
Лопатой в голову за такое надо давать :-) Знать что оно быстрее - хорошо, постоянно думать об этом - смерть поректу.
Никто не говорит про то, что следует постоянно думать об этом. Главное - знать, что работает быстрее.
> 1 Если метод может быть статическим, объявляйте его статическим.
> 7 require_once дорого обходится.
> 18 Сообщения об ошибках дорого стоят
Согласитесь, это мудацтво. Ведь метод либо статический либо нет. Как он "может быть" статическим? require_once дорого обходится. И что теперь? Раз в день весь проект и фреймворк перефигачивать чтоб все было на одних require'ах и по возможности без once? Сообщения об ошибках? Да их вообще не должно быть!

> 30 PHP-скрипты будут обрабатываться, как минимум, в 2-10 раз медленнее, чем статические HTML-страницы. Попробуйте использовать больше статических HTML-страниц и меньше скриптов.
Нет слов.

В общем, несколько замечаний есть действительно весомых, но остальное - такой бред, что стыдно за php стает, так как относятся они к повседневной жизни слабо либо вообще не относятся к ней.
ты что! require - это же целая эпопея - надо файлик найти, надо его скомпилить, подключить код! Зачем, это слишком нагружает сервер. Настоящие пацаны пишут все в одном файле.
И да! Генерируй хтмл-файл раз в 5 минут, и давай юзеру ссылку на хтмл, не на пхп. Черт с ней, с актуальностью инфы. Скорость важнее!
Похоже на "Вредные Советы" Остера
очень, очень сумбурная статья, всё в кучу.

ниже попробую разделить "советы" на классы так, как я их вижу:

I. не оптимизация, а правила здравого смысла, хорошего тона и культуры программирования. по большей части не имеют отношения непосредственно к php:

13 (сильно удивился что следующим пунктом не было ничего про switch), 1, 9, 10, 11, 17, 18, 23, 24, 28, 36, 39

II. Оптимизации очень низкого уровня, имеющие смысл разве что внутри очень длинных циклов и занимающие большой процент времени:

29 (то же самое что и 3), 40 (если это имеет смысл. например 90% времени уходит на эти функции и реализация на C будет как минимум разы эффективнее)

III. советы, ведущие к отказу от важных плюшек, предоставляемых языком в угоду несущественной оптимизации. Подобные прблемы должны быть проблемой транслятора, а не программиста (aka "с таким подходом вам бы на чистом C писать..."):
5, 6, 7, 8, 21, 22, 26, 27, 33 (хак!), 34, 35,


IV: резонно, но если выполнимо, то скорее относится к первому пункту.

2, 14, 19

V: действительно разумный подход к оптимизации - взваливание проблем на внешние решения, не требующие модификации кода:
15, 31

VI: пункты, вызвавшие у меня недоумение, непонимание, или смех. Если кто-то с ними согласен, пожалуйста, объясните что к чему.

16. зачем это вдруг???

30. это примерно то же, что и 29, только в профиль и на другом уровне. в принципе, резонно, но уж слишком очевидно чтобы упоминать в списке.

32 - первая половина - пункт V, вторая - то же что 31.

37. помимо повторного использования есть и другие мотивы разбиения методов!

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

41. это техника, совершенно в стороне от остального.

42. никакого отношения к пхп не имеет. имел бы - был бы в разделе V.
Было: if (strlen($foo) < 5) { echo "Foo is too short"; }
Стало: if (!isset($foo{5})) { echo "Foo is too short"; }
---
Может вместо !isset лучше использовать empty?))
А может почитать мануал, прежде чем давать такие советы?

$s = 'hello0';
var_dump (empty($s{5}));
Прочтите http://habrahabr.ru/blog/php/39115.html и поймите, что вы неудачник.
Sign up to leave a comment.

Articles