Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 201
объясните почему не рекомендуют использовать __autoload. Это же очень удобно и спасает от исползования requece_once. А так список очень полезен. В закладки однозначно (они есть не просят :))
дополню вопрос: а если регистрировать автолоадер через spl, будет ли потеря скорости? у меня не наблюдается, профайлер показывает что это не является чем-то существенным.
Проще говоря, ООП во многих ситуациях приносит вред, усложняет разработку и замедляет выполнение кода.
А можно привести пример хотя бы одной ситуации такой?
А можно привести пример хотя бы одной ситуации такой?
Наверное, ООП не умеют пользоваться. Это действительно нередко.
ООП не ради ООП делается, а ради эффективности. Не умеешь писать _хороший_ ООП-код — лучше не пиши.
Я вот на Pascal за несколько лет не научился, и на php не пробую )
Ну а про медленность явно сказано. В 2-3 раза это немало.
ООП не ради ООП делается, а ради эффективности. Не умеешь писать _хороший_ ООП-код — лучше не пиши.
Я вот на Pascal за несколько лет не научился, и на php не пробую )
Ну а про медленность явно сказано. В 2-3 раза это немало.
Мы не берем людей, которые считают что ооп - это класс-неймпспейс со своими функциями и переменными. Это отдельная тема для разговора.
Очень жаль что не научились, к примеру мне хватило полугода что бы понять все основные принципы и фишки, и потом еще много много месяцев что бы понять как их правильно использовать и где (до сих пор понимаю, что этот прогресс не останавливается).
А насчет медленности - опять же, не факт. К примеру я использую в качестве шаблонизатора XSLT, я думаю не стоит говорить, что именно это самое ресурсоемкое место, по сравнению с которым вытаскивание и взаимодействие 20 классов (не считая таких ресурсоемких операций как работа с бд в адаптере для бд) - это как замена использования $array[key] на $array['key'].
А удобство от этих 20 классов неоспоримое, потому как мне больше никогда не приходится думать о том, как же изъебнуца что бы впихнуть в существующий функционал что-то такое новое, или исправить поведение некоторых вещей..
Очень жаль что не научились, к примеру мне хватило полугода что бы понять все основные принципы и фишки, и потом еще много много месяцев что бы понять как их правильно использовать и где (до сих пор понимаю, что этот прогресс не останавливается).
А насчет медленности - опять же, не факт. К примеру я использую в качестве шаблонизатора XSLT, я думаю не стоит говорить, что именно это самое ресурсоемкое место, по сравнению с которым вытаскивание и взаимодействие 20 классов (не считая таких ресурсоемких операций как работа с бд в адаптере для бд) - это как замена использования $array[key] на $array['key'].
А удобство от этих 20 классов неоспоримое, потому как мне больше никогда не приходится думать о том, как же изъебнуца что бы впихнуть в существующий функционал что-то такое новое, или исправить поведение некоторых вещей..
> ООП замедляет код всегда. И многое из того что было сказано в статье тоже.
Другое дело что можно весь проект написать в виде одного лишь index.php с низкоурвневыми функциями типа mysql_*
А ещё лучше написать все через модуль Apache на C.
Это я всё к тому что бессмысленно жертвовать качеством кода и удобством его сопровождения ради быстродействия. Прикупить железа будет проще. А вот если есть возможность повысить производительность приложения без ущерба - тогда и только тогда стоит пользоваться советами этой статьи. А так, конечно тот же __autoload очень удобен.
Другое дело что можно весь проект написать в виде одного лишь 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 проверяет загружен ли тот класс методов который используется при вызове метода.
Естественно, при нормальных ресурсах и правильном кэшировании всего этого дела, ее можно использовать, но с опаской того, что при чтении кода сложно понять где подключается тот или инной класс - что является плохой структуризацией кода в проекте и не применимо в больших проектах.
На счет закладок ты полностью прав - это может послужить хорошим списком правил для начинающих в программировании. Автору и переводчику спасибо!
2. Но для того чтоб выполнить свое назначение, ей приходится при каждом создании объекта проверять загружена ли в память ссылка на кэш или на файл класса.
3. Мы конечно же можем создавать малое количество объектов на один вызов скрипта, но как быть со статическими методами, которые при правильном программировании используется больше чем создание объекта, ведь __autoload проверяет загружен ли тот класс методов который используется при вызове метода.
Естественно, при нормальных ресурсах и правильном кэшировании всего этого дела, ее можно использовать, но с опаской того, что при чтении кода сложно понять где подключается тот или инной класс - что является плохой структуризацией кода в проекте и не применимо в больших проектах.
На счет закладок ты полностью прав - это может послужить хорошим списком правил для начинающих в программировании. Автору и переводчику спасибо!
>> Было: 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"
В мануале написано так: "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 устаревшими являются квадратные, а не фигурные скобки.
До выхода PHP 6 устаревшими являются квадратные, а не фигурные скобки.
неоднозначный в том смысле, что при слабой типизации пхп, ты не сможешь сказать - чем является переменная, массивом или строкой, и код $var[$index] вполне может быть истолкова и так и так.
>> что опять не правда
http://ru2.php.net/manual/ru/language.ty… ("Доступ к символу в строке и его изменение")
>> что опять не правда
http://ru2.php.net/manual/ru/language.ty… ("Доступ к символу в строке и его изменение")
В случае, когда вместо строки переменная будет массивом.
логическая цепочка мыслей, которая формируется, когда программист видит конструкцию strlen($foo) <5 меньше , чем когда он видит !isset($foo{5}) .
А можно ещё каждую строку словами комментировать, чтобы уж совсем просто было.
лучше писать так, чтобы не приходилось комментировать :-)
Вы параллельно с написанием кода еще и его обфускацией занимаетесь? Не лучше ли оптимизировать БД, файловую систему, или добавить еще пару мегабайт памяти, чем гоняться за каждым тактом процессора?
Не надо рубить с плеча...
У каждого програмиста свой стиль и своя "специализация".
Кто-то силен в архитектуре, кто-то в "факторинге" кода.
Так вот "архитектор" может такую конструкцию при быстром просмотре кода и "просмотреть"... и потратить лишнее время.
а секономленая наносекунда... особенно при нынешней производительности серверов... и качественных "систем" кеширования становится бесполезной.
Вот если бы это был стиль "по умолчанию" (расписанный во всех учебниках и "практически" применяемый во многих языках!) - тогда другое дело, а так... сомнительное "ускорение". А учитывая что нормальный програмер знает не один только php и как минимум в день програмирует на разных языках... к концу рабочего дня могут быть и косяки. А это гараздо хуже
У каждого програмиста свой стиль и своя "специализация".
Кто-то силен в архитектуре, кто-то в "факторинге" кода.
Так вот "архитектор" может такую конструкцию при быстром просмотре кода и "просмотреть"... и потратить лишнее время.
а секономленая наносекунда... особенно при нынешней производительности серверов... и качественных "систем" кеширования становится бесполезной.
Вот если бы это был стиль "по умолчанию" (расписанный во всех учебниках и "практически" применяемый во многих языках!) - тогда другое дело, а так... сомнительное "ускорение". А учитывая что нормальный програмер знает не один только php и как минимум в день програмирует на разных языках... к концу рабочего дня могут быть и косяки. А это гараздо хуже
А я поддерживаю автора в этом плане. Подобная конструкция не намного сложнее, она понятна и прозрачна (для меня — да). Кроме того, из неё можно сделать традицию, как это было со многими код-куками.
А если говорить об экономии времени, то надо сравнивать не скорости интерпретации страницы компом или кода программистом, а их порядок, т. е. порядок программистов и порядок пользователей продукта. Если у продукта десять проггеров и десять пользователей, то конечно стоит отдавать предпочтение «привычному» коду )
А если говорить об экономии времени, то надо сравнивать не скорости интерпретации страницы компом или кода программистом, а их порядок, т. е. порядок программистов и порядок пользователей продукта. Если у продукта десять проггеров и десять пользователей, то конечно стоит отдавать предпочтение «привычному» коду )
Большинство приемов даст мизерный прирост производительности. Настолько мизерный, что часто не имеет смысла вообще тратить на это время. Лучше за это время подумать над каким-нибудь запросом к БД или об общей архитектуре приложения. А print-->echo, "-->' — это фигня.
Все мизерное при определенной нагрузке становится существенным.
Возможно это и не касается '->", print->echo, а вот preg_replace -> strtr - явно...
Ну и конечно главное внимание стоит уделать БД и работой с ней..а потом уже такие методы.
Возможно это и не касается '->", print->echo, а вот preg_replace -> strtr - явно...
Ну и конечно главное внимание стоит уделать БД и работой с ней..а потом уже такие методы.
Здесь я согласен, верная архитектура гораздо важнее. Однако мне, как поклоннику красивого кода, было исключительно интересно ознакомиться с этим списком.
И что же в этом списке относится к красивому коду? Замена очевидного кода на неочивидный?
Замена быстрого кода на чуть более быстрый. Выигрыш минимальный, но он есть.
есть большая разница между красивым кодом и оптимизированным.
Первый легок для понимания и сам показывает ошибки (Пример: if(0=i))
Второй бывает нужен в узких местах, но точно не для повседневного использования. Слишком велики затраты на вникание в код каждого нового программиста.
з.ы.
Я люблю именно красивый код, но последнее время занимаюсь оптимизацией.
Первый легок для понимания и сам показывает ошибки (Пример: if(0=i))
Второй бывает нужен в узких местах, но точно не для повседневного использования. Слишком велики затраты на вникание в код каждого нового программиста.
з.ы.
Я люблю именно красивый код, но последнее время занимаюсь оптимизацией.
Гммм) melk, возможно, Вы имели ввиду... if(0==i) ??? А то как то Ваш пример не похож на "именно красивый код")))
да нет. как раз if (0 =$i)
ибо в такой ситуации компилятор обругает за попытку присвоения константе, при этом вариант if ($i = 0) остается вполне легальным, хотя и сделает не совсем то что обычно требуется (==)
ибо в такой ситуации компилятор обругает за попытку присвоения константе, при этом вариант if ($i = 0) остается вполне легальным, хотя и сделает не совсем то что обычно требуется (==)
я сам ошибся... я имел ввиду if(0==$i)... а ваш пример работать все равно не будет... вам нужно сравнивать, а вы присваеваете.
всё! спать! :D
да! у Вас всё было правильно!
но я еще толком не проснулся и прочитал Ваш вариант с точностью до наоборот, т.е. обычный вариант когда переменная слева а константа справа.
и сунулся объяснять почему «константа слева» приятнее.
а на счет того что мой пример не сработает, дык в том-то и фокус (типа для иллюстрации).
и только после вашего комментария («я сам ошибся... я имел ввиду if(0==$i)...»), когда начал смотреть где ошибка, я понял что писал спросонья и неправильно Вас понял :")
приношу извинения.
да! у Вас всё было правильно!
Гммм) melk, возможно, Вы имели ввиду... if(0==i) ???
но я еще толком не проснулся и прочитал Ваш вариант с точностью до наоборот, т.е. обычный вариант когда переменная слева а константа справа.
и сунулся объяснять почему «константа слева» приятнее.
а на счет того что мой пример не сработает, дык в том-то и фокус (типа для иллюстрации).
и только после вашего комментария («я сам ошибся... я имел ввиду if(0==$i)...»), когда начал смотреть где ошибка, я понял что писал спросонья и неправильно Вас понял :")
приношу извинения.
Пункты 3 и 29 - вообще одно и тоже ... автору списка - дизреспект
15 и 42 - тоже, причем, если мне не изменяет память, как раз mod_deflate сжимает на лету, в то время как mod_gzip делает сжатие через временный файл.
Я тоже заметил :)
Но перевод - есть перевод, убирать пункт я не стал.
Да и "Повторение - мать учения" :)
Но перевод - есть перевод, убирать пункт я не стал.
Да и "Повторение - мать учения" :)
Спасибо! Пригодится.
P.S.: Следовало бы разделить этот список на разделы, а так все перемешано.
P.S.: Следовало бы разделить этот список на разделы, а так все перемешано.
Совет 44-й: заюзайте профайлинг и начните выполнять оптимизацию в тех местах, где она действительно необходима
За 33-й пункт убил бы (не дай бог так начнут писать). А вообще, задал бы автору вопрос: вы особираетесь бороться за написание самого оптимизированного скрипта в мире, или решаете задачи эффективного программирования (отношение [затраченные деньги==затраченное время]/результат). Прироста в 2 раза можно добиться и путем покупки сервера в 2 раза мощнее. Про кеширование надо помнить, это да. Остальное даст малый прирост, но лишней возьни с этим будет много. 17 — а что, так еще кто-то пишет? О_о
если следовать указанным советам, можно ускорить работу скрипта вкупе на 1% и получить отличный неподдерживаемый говнокод
ура, товарищи
ура, товарищи
> Закрывайте свои соединения с БД, когда закончите работать с ними.
В этом есть какой-то тайный смысл o_0' ? После выполнения скрипта соединение же закроется само...
В этом есть какой-то тайный смысл o_0' ? После выполнения скрипта соединение же закроется само...
точно такой же как и в высвобождении памяти, при условии что её хватает на нормальную работу скрипта
смысл в том, что при высокой нагрузке(большом количестве запросов к странице которая неадекватно использует память), может банально нехватать памяти сервера, что будет приводить к общим тормозам.
Для большого количества запросов существует кеширование (пункт, кстати, 31-й), банальная оптимизация запросов и увеличение мощностей сервера, как уже писали выше.
чем закрытие соединения экономит память? неужели накладные расходы на хранение хандлера так высоки? не верю
извиняюсь - ошибся комментом. это я про освобождение памяти
не сталкивался ни разу с явлением
скрипты всегда вполне помещаются в 16мб, и почти всегда в 8мб
к тому же неизвестно ещё как будет в этом случае действовать сборщик мусора в пхп
скрипты всегда вполне помещаются в 16мб, и почти всегда в 8мб
к тому же неизвестно ещё как будет в этом случае действовать сборщик мусора в пхп
"битрикс. управление сайтом" минимальное требование оперативки - 32М. Это нормально? Вот для таких и нужна эта статья.
И вообще всегда будет работать принцип: создал - уничтожь, открыл - закрой, и тп. А то, что PHP за нас делает половину работы, за это мы расплачиваемся производительностью и безопасностью.
И вообще всегда будет работать принцип: создал - уничтожь, открыл - закрой, и тп. А то, что PHP за нас делает половину работы, за это мы расплачиваемся производительностью и безопасностью.
У же несколько раз встречал в сети эти советы, но на аглицком. Каждый раз они провоцируют бурное обсуждение... Многие советы спорные или являются "экономией на спичках". Выигрыш от них будет ничтожно мал в сравнении, например, со временем обращения к БД и временем работы не оптимального алгоритма.
Советы на подобие п.33 вообще считаю вредными, та же экономия на спичках, но как минимум затрудняет дальнейшую поддержку кода.
Про строки в двойных и одинарных кавычках:
разница может и есть, но только при разборе скрипта и сводится к нули при использовании кешера байткода. Специально в цикле делал eval строки в одних и других кавычках, на миллионе итераций особой разницы не заметил. Согласен, что $a['key'] логичнее $a["key"], но в подобном случае
$s = "<tr>".
"<td>$Key".
"<td>$Value".
"</tr>\n";
лично мне удобнее использовать одинаковые кавычки, независимо от того, есть в строке переменные или нет (но так и не смог убедить в этом шефа...)
Гораздо более впечатляющего результата можно достичь оптимизацией SQL-запросов, алгоритмов или структуры приложения.
P.S.
В который раз не могу понять как 42-й пункт соотносится с оптимизацией PHP-кода.
Советы на подобие п.33 вообще считаю вредными, та же экономия на спичках, но как минимум затрудняет дальнейшую поддержку кода.
Про строки в двойных и одинарных кавычках:
разница может и есть, но только при разборе скрипта и сводится к нули при использовании кешера байткода. Специально в цикле делал eval строки в одних и других кавычках, на миллионе итераций особой разницы не заметил. Согласен, что $a['key'] логичнее $a["key"], но в подобном случае
$s = "<tr>".
"<td>$Key".
"<td>$Value".
"</tr>\n";
лично мне удобнее использовать одинаковые кавычки, независимо от того, есть в строке переменные или нет (но так и не смог убедить в этом шефа...)
Гораздо более впечатляющего результата можно достичь оптимизацией SQL-запросов, алгоритмов или структуры приложения.
P.S.
В который раз не могу понять как 42-й пункт соотносится с оптимизацией PHP-кода.
Люблю оптимизировать все и вся, даже если эффект мизерный. Уже встречал совет 3 и даже пытался писать так - зачастую жутко неудобно. Решил провести тест и, хоть убейте, не вижу преимущества вывода через запятую - он медленнее в большинстве случаев на порядок.
Покажите мне реальные результаты, на основании которых даются такие советы.
Покажите мне реальные результаты, на основании которых даются такие советы.
';
$start = microtime(true);
ob_start();
for ($i = 0; $i ';
$start = microtime(true);
ob_start();
for ($i = 0; $i ';
гхм, парсер лох... :-)
http://pastebin.ru/292790
http://pastebin.ru/292790
Спасибо, теперь понятно, почему мои тесты показывали другие результаты - если убрать буферизацию, то получим бОльшие тормоза за счет бОльшего числа 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
$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.
30-й совет по оптимизации PHP улыбнул - не использовать PHP :)
33-й совет работает только если у вас однобайтные строки, весь мир уже давно на utf8 перелез, а в PHP (до сих пор) utf8 нативно не держится - только через расширения для поддержки мультибайтных строк, типа mb_string... Соответственно, надо юзать стандартный strlen, потому что php-кодер не должен полагаться на однобайтные символы, мало ли, может, админ включил mbstring.func_overload (особенно актуально для тех, кто пользуется сторонним хостингом)...
Получается, что все перечисленные советы для "начинающих", т.к. "продолжающие" и сами знают, где и как чего оптимизировать у себя. А "начинающие" вообще не должны заниматься оптимизацией - вредно для психики. Premature optimization is the root of all evil.
Дальше 17 пункта читать не стал.
Советы очень неплохие,
насчет этого не уверен тоже
# Методы в производных классах работают быстрее, чем они же, определённые в базовом классе.
А так все супер, а насчет ООП - какой смысл делать ОО например скрипт который забирает тИЦ с Яндекса? Вещь одноразовая - написал и забыл, ООП хорошо использовать в больших проектах, для маленьких скриптов это просто глупо будет и все, достаточно модульного подхода (время паскаля еще не прошло) =)
насчет этого не уверен тоже
# Методы в производных классах работают быстрее, чем они же, определённые в базовом классе.
А так все супер, а насчет ООП - какой смысл делать ОО например скрипт который забирает тИЦ с Яндекса? Вещь одноразовая - написал и забыл, ООП хорошо использовать в больших проектах, для маленьких скриптов это просто глупо будет и все, достаточно модульного подхода (время паскаля еще не прошло) =)
почти наверняка этот скрипт будет работать также в паре со скриптом, который "забирает" PR гугла, наличие в DMOZ или ище где
почти наверняка у этих классов общими будут 90% кода. почему бы не вынести? :-)
при этом получить хороший (переносимый) код :-)
почти наверняка у этих классов общими будут 90% кода. почему бы не вынести? :-)
при этом получить хороший (переносимый) код :-)
*ещё
(боже мой :-) )
(боже мой :-) )
А нельзя сделать это функциями? И в них заложить 90% кода? Вот в С++ мне ООП очень нравиться, и я вижу смысл его использовать, в PHP уж простите в 90% лично мне хватает модульного подхода, ну ненравиться мне реализация ООП в нем.
90% кода общего (абстрактный класс), 10% частного - наследники
ляпота? :-)
>> ну ненравиться мне реализация ООП в нем.
конкретики требуют рабочие классы! :-)
ляпота? :-)
>> ну ненравиться мне реализация ООП в нем.
конкретики требуют рабочие классы! :-)
ООП применяется для организации очень сложных проектов - если его применять к простым поектам (это подавляющее большинство Web-проектов) ничего, кроме того, что простой проект превратиться в сложный не произойдёт. Применяются эти конструкции в очень сложных проектах, когда от базового класса до конечного - 10 иерархий наследования, т.е. 10 уровней абстракций
кварк
ядро
атом
молекула
супермолекула
фермент
клетка
орган
организм
социальная группа
При моделировании такой системы очень велик соблазн в целях производительности конечной системы срезать углы. Т.е для управления социальной группой не человека управленца вывести, а орган, который не будет являться организмом, но зато его создать проще и он впрыскивает нужные ферменты непосредственно в мозг индивидумов. Да быстрее, да эффективнее - но ошибок при такой архитектуре будет больше, а масшатбируемости меньше. Для того, чтобы снизить соблазн вводятся интерфейсы, абстрактные классы и полиморфизм (последний преследуем немного другие цели).
ООП в PHP - это копия объектно-ориентированной модели Java, он просто скопирован и всё, а сам язык во многом копирует Perl - а это противоречивые технологии. ООП введён для снижения сложности монолитных графических программ и библиотек, а Perl и PHP для снижения сложности CLI-интерфесных прогрмм (интерфейс командной строки). UNIX и ООП - это несовестимые вещи, первый преследует разделеление сложности на уровне мелких взаимодействующих программ, каждая из которых выполняет свои цели, а второй разделение монолитных программ и библиотек, больше характерных для графического интерфейса, принятого в среде Windows и Macintosh.
Я могу привести 1000 примеров удачного применения ООП в Windows, но почти ни одного в PHP-программировании - философия разная...
кварк
ядро
атом
молекула
супермолекула
фермент
клетка
орган
организм
социальная группа
При моделировании такой системы очень велик соблазн в целях производительности конечной системы срезать углы. Т.е для управления социальной группой не человека управленца вывести, а орган, который не будет являться организмом, но зато его создать проще и он впрыскивает нужные ферменты непосредственно в мозг индивидумов. Да быстрее, да эффективнее - но ошибок при такой архитектуре будет больше, а масшатбируемости меньше. Для того, чтобы снизить соблазн вводятся интерфейсы, абстрактные классы и полиморфизм (последний преследуем немного другие цели).
ООП в PHP - это копия объектно-ориентированной модели Java, он просто скопирован и всё, а сам язык во многом копирует Perl - а это противоречивые технологии. ООП введён для снижения сложности монолитных графических программ и библиотек, а Perl и PHP для снижения сложности CLI-интерфесных прогрмм (интерфейс командной строки). UNIX и ООП - это несовестимые вещи, первый преследует разделеление сложности на уровне мелких взаимодействующих программ, каждая из которых выполняет свои цели, а второй разделение монолитных программ и библиотек, больше характерных для графического интерфейса, принятого в среде Windows и Macintosh.
Я могу привести 1000 примеров удачного применения ООП в Windows, но почти ни одного в PHP-программировании - философия разная...
огромный пост, и ни слова в ответ "что не так в реализации объектной модели в пхп"
Одна из серьезных проблем ООП в PHP 5 уже была озвучена. Это отсутствие модификатора наследования.
Отсутствие возможности множественного наследования.
Конструктор базового класса не вызывается по умолчанию из конструктора наследника.
Следствием отсутствия строгой типизации является отсутствие возможности перегрузки функций.
В PHP 5 есть возможность указать тип аргумента функции (только для классов и массивов). Если переданный аргумент не будет соответствовать требуемому типу, возникнет ошибка и функция вызвана не будет.
Отсутствие нормального определения виртуальных свойств и методов класса (свойств, которые имеют геттеры и сеттеры).
Открытость классов.
Смешение статических и нестатических методов и свойств.
Объектно-ориентированные языки поддерживают создание структур с большим количеством связующего кода и сложными уровнями. Это может оказаться полезным в случае, если предметная область является действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому, что им известны эти способы и они умеют ими пользоваться.
Эрик. С. Реймонд. Искусство программирования для UNIX.
Отсутствие возможности множественного наследования.
Конструктор базового класса не вызывается по умолчанию из конструктора наследника.
Следствием отсутствия строгой типизации является отсутствие возможности перегрузки функций.
В PHP 5 есть возможность указать тип аргумента функции (только для классов и массивов). Если переданный аргумент не будет соответствовать требуемому типу, возникнет ошибка и функция вызвана не будет.
Отсутствие нормального определения виртуальных свойств и методов класса (свойств, которые имеют геттеры и сеттеры).
Открытость классов.
Смешение статических и нестатических методов и свойств.
Объектно-ориентированные языки поддерживают создание структур с большим количеством связующего кода и сложными уровнями. Это может оказаться полезным в случае, если предметная область является действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому, что им известны эти способы и они умеют ими пользоваться.
Эрик. С. Реймонд. Искусство программирования для UNIX.
а по поводу "ооп в ос", хрестоматийнее вспоминать beos/haiku
Вы не совсем верно уловили суть совета.
Рекомендуется не отказываться от ООП, а не совать его везде, где его можно применить.
Рекомендуется не отказываться от ООП, а не совать его везде, где его можно применить.
у меня точка зрения на вопрос доведена до крайности - если код будет в принципе поддерживаться и развиваться дальше, он обязательно должен быть написан в соответствии с ОО парадигмой
Поясните столь резкое утверждение.
Я так понимаю, ответ на мой вопрос "Нет таких задач, в которых без ООП - лучше".
Элементарный пример - гостевая книга. Можно написать с ООП, постепенно превращая в монстра. А можно использовать функции и получить более быстрый и простой код, не запутывая эту простоту.
Одна из основ РНР - простота использования. ООП усложняет эту простоту.
P.S. В будущем если хотите получить чёткий ответ - выражайтесь яснее. "Вы разве не понимаете, что это чушь?" и "Вы какую задачу решать собрались?" - не являются ясными высказываниями.
Элементарный пример - гостевая книга. Можно написать с ООП, постепенно превращая в монстра. А можно использовать функции и получить более быстрый и простой код, не запутывая эту простоту.
Одна из основ РНР - простота использования. ООП усложняет эту простоту.
P.S. В будущем если хотите получить чёткий ответ - выражайтесь яснее. "Вы разве не понимаете, что это чушь?" и "Вы какую задачу решать собрались?" - не являются ясными высказываниями.
Человек ксати еще привык решать задачи так, как он давно уже привык. Поэтому если человек в поседневной жизни использует ооп механизмы то, даже простейшие задачи он будет решать с помощью объектов и их взаимоотношений.
Это не плохо. Это просто другой подход, для которых он подходит идеально, а для других - как что-то такое тяжелое и многовесное, непонятное и вообще ненужное.
К примеру я тоже бы даже самую простейшую задачу решил с помощью ооп, ибо для меняэ то проще, я не люблю писать по много раз один и тот же код, который делает одни и те же вещи. А как показала моя практика, в очень многих задачах есть очень много мест где код просто напросто дублируется. Практически полностью...
Это не плохо. Это просто другой подход, для которых он подходит идеально, а для других - как что-то такое тяжелое и многовесное, непонятное и вообще ненужное.
К примеру я тоже бы даже самую простейшую задачу решил с помощью ооп, ибо для меняэ то проще, я не люблю писать по много раз один и тот же код, который делает одни и те же вещи. А как показала моя практика, в очень многих задачах есть очень много мест где код просто напросто дублируется. Практически полностью...
Я придерживаюсь правила, что надо писать логически понятный и красивый код, который асимптотически работает быстро. Извращаться с нетривиальными и deprecated- конструкциями ради лишней микросекунды - удел горе-оптимизаторов. Хочешь скорости - пиши на C.
32 — вообще не имеет отношения к php, но достаточно грамотно при общем подходе.
1,35 — алилуя! Дяденька бог, сделай, пожалуйста, так, чтобы объектная модель в php сдохла, а статические классы выжили.
3,33 — не знал, интересно!
Автору спасибо,
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
ИМХО нужно подкорректировать это высказывание:
но 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.2 секунды... так ли это важно?
Объясните, "" медленнее, чем ''. Но '1 ' . $v . ' 2' медленнее, чем "1 $v 2", т.е. в первом случае конкатинация, а во втором просто лишний jump в StateMachine(лексический анализатор)
Да и имхо вообще простая оптимизация SQL-запросов увеличит производительность поболее, чем все эти советы.
Вы даете советы и говорите что echo работает быстрее print или require_once дорого обходится, а тесы вы проводили? Почему вы решили что дольше? Меня интерисует больше доказательство этого, чем просто бла-бла-бла )
21, 24 - уже маразм, глобальные переменные уже сами по себе зло, люди уже давно придумали конструкторы\параметры функций\делегирование и т.д. и т.п. и возвращение результата.
37, 38 - наверно автор не читал Мартина Фаулера ....
37, 38 - наверно автор не читал Мартина Фаулера ....
И вообще, такая оптимизация ничего не дает на самом деле даже на высоконагруженных проектах. Потому что в этом случае производительность пхп особой роли не играет, всегда можно сделать балансировку на нескольких бэкэндах. Да и кэширование даст куда больший выигрыш.
Главное, не писать откровенно корявый код, подвешивающий сервак даже на простых проектах. Видел я сайт одного провинциального автосалона (ясно, что посетилово у него никакое), так вот, некоторые страницы у него открывались по 30-40 секунд. Посмотрел код страницы, а там разработчики в конце комментом зафигачили время генерации страницы и количество запросов. Так вот, время генерации у них и было 30-40 секунд, а количество запросов - более 2000. Ладно еще кеш был, живущий одну минуту (хотя на странице за это время ничего не меняется).
Главное, не писать откровенно корявый код, подвешивающий сервак даже на простых проектах. Видел я сайт одного провинциального автосалона (ясно, что посетилово у него никакое), так вот, некоторые страницы у него открывались по 30-40 секунд. Посмотрел код страницы, а там разработчики в конце комментом зафигачили время генерации страницы и количество запросов. Так вот, время генерации у них и было 30-40 секунд, а количество запросов - более 2000. Ладно еще кеш был, живущий одну минуту (хотя на странице за это время ничего не меняется).
:-D
Ссылку не дадите?
Ссылку не дадите?
подобная оптимизация скорее хороший тон, нежели гонка за сокращением машинного времени. Да и потом, liveinternet.ru, самая крупная система статистики в рунете, стоит на одном сервере, на одном. Конечно, можно рассуждать как вы, мол какие проблемы, воткнуть несколько бэкендов и все дела, а можно пооптимизировать все подряд и экономить. Между 3-х литровым атмосферником и 1.8 турбиной я выберу турбину. Мощность та же, а вот экономия больше.
Да и потом, оптимизация бэкенда хотя бы на 0,01 секунды за сессию на высоконагруженных сервисах это огромный плюс.
Да и потом, оптимизация бэкенда хотя бы на 0,01 секунды за сессию на высоконагруженных сервисах это огромный плюс.
Если вы, грубо говоря, получаете с проекта миллион долларов, то не пофиг ли, сколько вы будете тратить на серверы - тыщу, две, три, пять?
Я и говорю, что надо писать красиво, а вот такие конструкции if (!isset($foo{5})) - это и есть гонка за машинным временем в ущерб читабельности и красивости кода.
P.S. Я знаю, что есть разные взгляды на понятие "красота кода". :)
Я и говорю, что надо писать красиво, а вот такие конструкции if (!isset($foo{5})) - это и есть гонка за машинным временем в ущерб читабельности и красивости кода.
P.S. Я знаю, что есть разные взгляды на понятие "красота кода". :)
Получи сначала с помощью 90% этих советов 0,01 секунды на сессию, умник.
А потом убедись, что грамотное кэширование делает ненужным практически весь этот список.
А потом убедись, что грамотное кэширование делает ненужным практически весь этот список.
выключи логирование ошибок, откажись от объектов, перейдя на статические классы — это уже даст не малый прирост производительности, если проект действительно высоконагруженный и это не «домашний» сайтик.
Видал код таких вот людей, которые готовы полностью все делать через мемкеш, мемкеш сервер упал и такой код валит сервак за секунды. Кеш это замечательно, но не панацея. Веб — отличная площадка для практики хорошего, быстрого кода за малые деньги. Ведь практически любое прикладное программирование не требует быстрой работы софта, тем более что чаще софт работает с одной сессией на мощной тачке. Зачем же губить эту площадку говнокодом с грамотным кешем?
Видал код таких вот людей, которые готовы полностью все делать через мемкеш, мемкеш сервер упал и такой код валит сервак за секунды. Кеш это замечательно, но не панацея. Веб — отличная площадка для практики хорошего, быстрого кода за малые деньги. Ведь практически любое прикладное программирование не требует быстрой работы софта, тем более что чаще софт работает с одной сессией на мощной тачке. Зачем же губить эту площадку говнокодом с грамотным кешем?
Не надо нести ерунду. про каких-то там людей, у которых все падает.
мемкеш - не синоним слова кэширование.
Я написал две простые вещи
1. Любой высоконагруженный проект использует кэширование.
2. Кэширование сводит на нет 90% этих советов.
Вот и все. И не надо перевирать мои слова.
Да и без кэширования большая часть этих советов - редкостный идиотизм и никакого реального влияния на производительность не оказывает.
Писать echo "Вася $abcd".$efgc; - не говнокод.
А вот человек, который будет писать 'Вася ',$abcd,$efgc; рассуждая о повышении производительности - профнепригодный даун
мемкеш - не синоним слова кэширование.
Я написал две простые вещи
1. Любой высоконагруженный проект использует кэширование.
2. Кэширование сводит на нет 90% этих советов.
Вот и все. И не надо перевирать мои слова.
Да и без кэширования большая часть этих советов - редкостный идиотизм и никакого реального влияния на производительность не оказывает.
Писать echo "Вася $abcd".$efgc; - не говнокод.
А вот человек, который будет писать 'Вася ',$abcd,$efgc; рассуждая о повышении производительности - профнепригодный даун
знаете, Дональд Кнут как-то сказал:
Premature optimization is the root of all evil. Что значит "преждевременная оптимизация — корень всех зол".
В топку большинство этих советов.
Premature optimization is the root of all evil. Что значит "преждевременная оптимизация — корень всех зол".
В топку большинство этих советов.
Особенно порадовала ссылка на статью 2005 года в пункте 43)))))
По поводу древности статьи:
тех, кто свято верит подобным советам, не смущают даже такие ископаемые как статья 5-тилетней давности http://php.spb.ru/php/speed.html, которая справедлива в лучшем случае для PHP4. Частенько вижу как эту статью советуют в ответ на вопрос об оптимизации PHP-кода. печально...
тех, кто свято верит подобным советам, не смущают даже такие ископаемые как статья 5-тилетней давности http://php.spb.ru/php/speed.html, которая справедлива в лучшем случае для PHP4. Частенько вижу как эту статью советуют в ответ на вопрос об оптимизации PHP-кода. печально...
"Удаляйте свои переменные для освобождения памяти, тем более, если это большие массивы."
Они сами мгновенно удаляются при выходе из области видимости.
Они сами мгновенно удаляются при выходе из области видимости.
пользуясь случаем, спрошу
как изучить PHP 5 за 24 часа?
как изучить PHP 5 за 24 часа?
#9 не рулит, ибо он без microseconds + мереет не только скорость php но и время реакции сервера на запрос. Лучше использовать microtime.
+ Стоило бы упомянуть о том что не надо использовать большие массивы, они адски едят память (пример 17000 эл-ов и по 15 вложенных) => 120мб.
+ Стоило бы упомянуть о том что не надо использовать большие массивы, они адски едят память (пример 17000 эл-ов и по 15 вложенных) => 120мб.
2. - еще бы автор оригинальной статьи бы вспомнил о шаблонизаторах - которые тоже медленней, нативного PHP + HTML, кстати индусы об этом знают - то-то никто шаблонизаторы не использует.
17. - Это к PHP3 наверное относится?!? Если писать "неправильно" - то будет "Notice" о необъявленной константе...
Т.е. этот пункт можно скрестить с 18-м - пиши код так, чтобы не вызывать ошибки, включите отображение ошибок <?php error_reporting(E_ALL)) ?>, и следите за чистотой кода...
35. - Индусы постигли сей пункт...
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.
viva ruby!
Некоторые советы очень плохие, это когда не ехать, а шашечки. Чем выигрывать 5-7% производительности, лучше писать хорошо поддерживаемый код. Сервера дешевеют, а вот программисты нет.
Если до такой степени гоняться за производительностью - лучше писать на C++
Если до такой степени гоняться за производительностью - лучше писать на C++
5-7% - это серьёзная оптимизация, на которую стоит затратить время и силы.
Бесспорно, хорошо поддерживаемый код - важнее :)
>Некоторые советы очень плохие
Но ведь некоторые - хорошие :) Значит мои усилия по переводу были не зря.
Бесспорно, хорошо поддерживаемый код - важнее :)
>Некоторые советы очень плохие
Но ведь некоторые - хорошие :) Значит мои усилия по переводу были не зря.
Да, некоторые хорошие, спасибо. (наверное с этого и надо было начинать)
5-7% - смотря какой ценой.
Иногда приходится слышать что-то типа:
- Zend Framework медленный, я его почикал - вырезал все комменты и в один файл засунул, получил 14% выигрыш в скорости. Правда, молодец я? :)
- А вы акселератор какой использовали?
- Да я... это... Ой, а чойто?
- Вы не молодец, вы батенька мудак :)
5-7% - смотря какой ценой.
Иногда приходится слышать что-то типа:
- Zend Framework медленный, я его почикал - вырезал все комменты и в один файл засунул, получил 14% выигрыш в скорости. Правда, молодец я? :)
- А вы акселератор какой использовали?
- Да я... это... Ой, а чойто?
- Вы не молодец, вы батенька мудак :)
Ну еще думаю, что чем тратить кучу времени на массированную ловлю блох, лучше немного подрихтовать модель и засунуть в проект еще больше кеширования.
Самый быстрый код - это код, которого нет ^_^
Самый быстрый код - это код, которого нет ^_^
Чувак.
Не надо так настойчиво и безнадежно страдать из-за низкой самооценки и искать оправдания.
Ему говорят, что текст - мусор, а он в ответ - "божья роса!". "Не зря переводил!"
Говно ты перевел. Говно.
Пойми это уже, наконец, и успокойся.
Нету там никаких 5-7%. Там и 0,5-0,7 нету, даже без акселерации и кэширования.
Писал это мальчик-дурачок, твой ровесник. Надергал по интернету мусора.
Не надо все написанное в интернете на английском априори считать кладезью мудрости.
Вреда от этого собрания куда больше, чем пользы. Опять будут бегать толпы малолетних идиотов-оптимизаторов.
Не надо так настойчиво и безнадежно страдать из-за низкой самооценки и искать оправдания.
Ему говорят, что текст - мусор, а он в ответ - "божья роса!". "Не зря переводил!"
Говно ты перевел. Говно.
Пойми это уже, наконец, и успокойся.
Нету там никаких 5-7%. Там и 0,5-0,7 нету, даже без акселерации и кэширования.
Писал это мальчик-дурачок, твой ровесник. Надергал по интернету мусора.
Не надо все написанное в интернете на английском априори считать кладезью мудрости.
Вреда от этого собрания куда больше, чем пользы. Опять будут бегать толпы малолетних идиотов-оптимизаторов.
Собственно, от наличия таких "гуру" как вы толпы малолетних халтурщиков и имеются.
Вы со мной не знакомы. Вы ни разу не видели меня, не общались со мной.
Всё, что вы знаете обо мне - это то, что я перевёл статью, которая не понравилась сообществу. Вы прочитали несколько моих высказываний о ней. Может быть, даже нашли в интернете что-нибудь обо мне.
Вы не знаете о моих умениях, а разговариваете со мной так, будто знакомы минимум неделю.
В следующий раз тщательно выбирайте выражения при общении со мной.
P.S. Если бы эта статья была глупой, она не вызвала бы такое обсуждение со стороны сообщества. Она заставила задуматься над оптимизацией кода и её смыслом десятки программистов, и это говорит мне о том, что я проделал свою работу не зря.
Всё, что вы знаете обо мне - это то, что я перевёл статью, которая не понравилась сообществу. Вы прочитали несколько моих высказываний о ней. Может быть, даже нашли в интернете что-нибудь обо мне.
Вы не знаете о моих умениях, а разговариваете со мной так, будто знакомы минимум неделю.
В следующий раз тщательно выбирайте выражения при общении со мной.
P.S. Если бы эта статья была глупой, она не вызвала бы такое обсуждение со стороны сообщества. Она заставила задуматься над оптимизацией кода и её смыслом десятки программистов, и это говорит мне о том, что я проделал свою работу не зря.
Ты идиот.
Судя по тому, что рейтинг как аффтара, так и его писулек, медленно но верно растет вверх, надежды явно не оправдались.
Лишний раз я убеждаюсь в том, что молчаливое большинство постетителей хабра - малолетние идиоты, неспособные понимать минимальную логику, с уровнем мышления обезьяны. обсуждение или не читают вовсе, или не поняли ни буквы. Как счастливый аффтар, который выискивает только положительные отзывы и с презрением отвергает отрицательные.
А вот про кавычки - вот это им доступно и понятно. поменял двойную на одинарную - и все начало летать.
Лишний раз я убеждаюсь в том, что молчаливое большинство постетителей хабра - малолетние идиоты, неспособные понимать минимальную логику, с уровнем мышления обезьяны. обсуждение или не читают вовсе, или не поняли ни буквы. Как счастливый аффтар, который выискивает только положительные отзывы и с презрением отвергает отрицательные.
А вот про кавычки - вот это им доступно и понятно. поменял двойную на одинарную - и все начало летать.
Кстати, вот и о "мальчике-дурачке, моём ровеснике" по имени Reinhold Weber
Не вижу там ничего, что расходилось бы с моей характеристикой.
Впрочем спасибо, почитал ещё раз, повнимательнее
http://reinholdweber.com/?p=1%20union%20select%201,2,3,4,user(),6,7,8,9
Убедился, что он такой же дебил, как и ты.
Впрочем спасибо, почитал ещё раз, повнимательнее
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).
Также, в статье приводятся доказательства, пояснения и примеры.
'' обрабатывалось быстрее чем "" до версии 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. Я невнимательно прочитал или там действительно не написано про двойные/одинарные кавычки?
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 стает, так как относятся они к повседневной жизни слабо либо вообще не относятся к ней.
> 7 require_once дорого обходится.
> 18 Сообщения об ошибках дорого стоят
Согласитесь, это мудацтво. Ведь метод либо статический либо нет. Как он "может быть" статическим? require_once дорого обходится. И что теперь? Раз в день весь проект и фреймворк перефигачивать чтоб все было на одних require'ах и по возможности без once? Сообщения об ошибках? Да их вообще не должно быть!
> 30 PHP-скрипты будут обрабатываться, как минимум, в 2-10 раз медленнее, чем статические HTML-страницы. Попробуйте использовать больше статических HTML-страниц и меньше скриптов.
Нет слов.
В общем, несколько замечаний есть действительно весомых, но остальное - такой бред, что стыдно за php стает, так как относятся они к повседневной жизни слабо либо вообще не относятся к ней.
Похоже на "Вредные Советы" Остера
очень, очень сумбурная статья, всё в кучу.
ниже попробую разделить "советы" на классы так, как я их вижу:
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.
ниже попробую разделить "советы" на классы так, как я их вижу:
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?))
Стало: if (!isset($foo{5})) { echo "Foo is too short"; }
---
Может вместо !isset лучше использовать empty?))
Прочтите http://habrahabr.ru/blog/php/39115.html и поймите, что вы неудачник.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
40 советов по оптимизации вашего PHP-кода