Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
1.А не выбрасывается ли результат с помощью echo, и использовать его советуют, потому что echo является функцией, как тот же printf, а относится к «конструкции языка»
2.>В таком случае прирост производительности дают как раз переменные вставленные в строки
А то что он лишний раз парсит строку и подставляет значения переменных?
2.>В таком случае прирост производительности дают как раз переменные вставленные в строки
А то что он лишний раз парсит строку и подставляет значения переменных?
*echo не является функцией
но что-то я прозевал, что речь идет о print
но что-то я прозевал, что речь идет о print
>А не выбрасывается ли результат с помощью echo, и использовать его советуют, потому что echo является функцией, как тот же printf, а относится к «конструкции языка»
Да, является конструкцией языка, оговорился, но в то же время в документации описывается и как функция.
Как я помню echo работает быстрее из-за того что в отличие от print не возвращает значения.
Известный факт, тестов не найду сейчас, что переменные вставленные в строку работают быстрее чем конкатенация.
Да, является конструкцией языка, оговорился, но в то же время в документации описывается и как функция.
Как я помню echo работает быстрее из-за того что в отличие от print не возвращает значения.
Известный факт, тестов не найду сейчас, что переменные вставленные в строку работают быстрее чем конкатенация.
Какой-же он известный, если в большинстве таких советов пишут, что конкатенация работает быстрее, да и внизу вам пример привели.
А самому проверить ;)
Ну сейчас не стоит вопрос самому проверить, выходит просто никому верить нельзя, даже автору этой статьи :D
Про конкатенацию я акцентрировал внимание на читабельность. Даже по тесту phpbench.com/ разница производительности ~1.5 — 2 раза. Время затрачиваемое на это операции, очень мало по сравнению с затратами времени на остальные операции. На этом экономить нет смысла.
Быть может и есть какие то совсем специфические приложения, где эта разница может сыграть существенную роль, но я таких не встречал.
Быть может и есть какие то совсем специфические приложения, где эта разница может сыграть существенную роль, но я таких не встречал.
Я поэтому тоже не заморачиваюсь, просто технические детали решил оспорить, а так и то правда, точить нужно совсем в других местах.
Мне было бы интересно проверить, как появляют на скорость уже на работающем под нагрузкой приложении удаление больших ресурсов.
И еще интересный момент. Писался движок блогов(увы, все равно загнулся, из-за финансирования), после полного переписывания на ооп с разбиением на небольшие классы и с примением абстрактных фабрик,, простеньких контроллеров и небольших моделей, производительность выросла раза в 2 раза. Запросы не оптимизировались. Остальная часть — строилось на mysql + xslt шаблоны. На сервере по слухам, туда доступа у меня не было кроме фтп — memcached на апаче + nginx.
До этого серсис блогов, был написан таким образом, что классы просто использовались как контейнеры функций.
И еще интересный момент. Писался движок блогов(увы, все равно загнулся, из-за финансирования), после полного переписывания на ооп с разбиением на небольшие классы и с примением абстрактных фабрик,, простеньких контроллеров и небольших моделей, производительность выросла раза в 2 раза. Запросы не оптимизировались. Остальная часть — строилось на mysql + xslt шаблоны. На сервере по слухам, туда доступа у меня не было кроме фтп — memcached на апаче + nginx.
До этого серсис блогов, был написан таким образом, что классы просто использовались как контейнеры функций.
А казалось бы, часто утверждают, что ООП добавляет времени на обработку скрипта.
Сам по себе да. Для PHP5 на различных серьезных ресурсах заявлялось что ООП код работает на 30% медленее процедурного. Но можно и без ооп, или просто используя неграмотно ООП технологии написать так, что будет исполняться медленней, чем при правильном применении ООП.
Плюс ООП подход ускоряет время самой разработки, и это себя хорошо оправдывает
Плюс ООП подход ускоряет время самой разработки, и это себя хорошо оправдывает
По поводу п. 2 я делал ряд тестов в споре с Joshua5. Для тестов использовал FreeBSD 6.2-RELEASE-p7 #1, PHP Version 5.1.2 и замечу, что разница в производительности составляет порядка ~1%, что для работающего сервера нивелируется другими факторам. Поэтому в настоящее время уже не имеет значение какой вариант использовать.
Кусок с тестами можно найти тут alekciy.ru/temp/test.html
Кусок с тестами можно найти тут alekciy.ru/temp/test.html
10 должно выглядеть так:
10. require() и include() идентичны во всех отношениях за исключением того, что require останавливает выполнение скрипта, в том случае, когда подключаемый файл не найден. Разница в скорости работы минимальна.А совета по сути там нет. Это скорее «антисовет» — типа не парьтесь над скоростью, разницы в них нет.
Спасибо, исправил :)
тем не менее принципиальная разница в работе у них есть.
В принципе работы или в скорости?
принципиальная разница. это разные конструкции, они выполняют разные задачи.
Причем тут это? Статья об оптимизации производительности
10. require() и include() идентичны во всех отношениях за исключением того, что require останавливает выполнение скрипта, в том случае, когда подключаемый файл не найден.
они не идентичны. возможно мне нужно было поправлять не вас, а автора перевода.
они не идентичны. возможно мне нужно было поправлять не вас, а автора перевода.
Почитать интересно, переводите и комментируйте дальше
А если серьезно, то такие статьи, по моему мнению, только ухудшают качество кода. Человек начинает программировать и пишет так, как «быстрей будет работать». В итоге у него получается якобы быстрый и очень непонятный код. Я лично не видел еще ни одного проекта, где выполнение php-скриптов занимало бы много времени. Всегда узким местом я видел SQL. Да наверное, это в любом проекте так. Я, например, видел статью, где сравнивалось вариантов 5 обхода массива элементов, и foreach там был самым медленным. Но хоть убейте, никогда не стану писать по другому. Вы получаете выигрыш в выполнении в тысячные милисекунды, но пишете больше кода, и пишете непонятный код. Куда важнее понять принципы программирования, правильное форматирование кода, грамотный SQL, чем искать такие места, где можно выиграть еще чуть-чуть сотых мс. В любом случае, затраты на поддержку штата программистов, которые будут писать более длинный, но быстрее работающий код, будут больше, чем покупка еще одного сервера для масштабирования нагрузок.
Поэтому я решил делать не просто перевод, а постарался рассмотреть смысл такой оптимизации. Ставя на первое место качество кода, удобство разработки и поддержки + постарался найти случаи, когда такая оптимизация может иметь смысл. И как говорят отцы программирования, делать это только после написания кода.
И конечно рад любой конструктивной критики. Для этого и писал. Все интересно в комментариях добавлю в статью, с указанием автора.
И конечно рад любой конструктивной критики. Для этого и писал. Все интересно в комментариях добавлю в статью, с указанием автора.
Любая крайность — зло. Нужно чувствовать баланс ;-)
да для начинающих программистов — эта статья яд, а вот для программистов чуть выше начала — необходимый минимум ибо не зная таких базовых вещей нельзя программировать хоть что-то адекватное. Нарушение таких правил бывает 2-х типов: первое по незнанию (совсем плохо) второе в угоду чему-то еще, вот второе еще можно оправдать (читаемостью / скоростью разработки и т.д.) То есть нет смыслу писать изначально плохо просто так. Если пишешь плохо — отдавай себе отчет ради чего это делаешь
Я, например, видел статью, где сравнивалось вариантов 5 обхода массива элементов, и foreach там был самым медленным.
Можно ссылку или, хотя бы, для какой версии PHP актуально?
От себя:
Про 4-ку не скажу, а в PHP5 foreach само то для обхода массива. Внутренняя структура, которой представляется в памяти массив, кроме всего прочего, имеет двусвязный список элементов для выполнения операций prev/next, и foreach это использует.
Большинство этих оптимизаций дают на порядки меньший прирост в реальных проектах, чем оптимизация архитектуры и способ запуска проекта (кеширование, оптимизация базы, выбор более легких серверов, например, nginx). eAccelerator и иже с ним сводят к нулю влияние конструкций языка на конечное время выполнения программы. Если вы даже посмотрите на тесты, то увидите, что различия проявляются только на большом числе итераций, в реальных проектах тех же print очень немного.
В случае, если вы действительно уперлись в скорость языка, то скорее всего вы либо гугл, либо пожалели деньги на хостинг:)
В случае, если вы действительно уперлись в скорость языка, то скорее всего вы либо гугл, либо пожалели деньги на хостинг:)
Я видел print в проектах, но редко. Мне он не мешает, поэтому я не писал четких указаний использовать то или то, а просто привел описание echo и print и обосновал почему print работает немного медленней. Это дело привычки, и само собой экономить на этом и переходить на echo, если вы всю жизнь использовали print нет смысла, и не призываю к этому :)
Про итерации я и написал, что прирост можно ощутить только на большом количестве итераций. Я старался сильно отталкиваться от опыта разработки, и что перевешивает в данном случае важнее — удобство, читабельность, подддержка кода или оптимизация. Там приведены тесты, и само собой на большом количестве итераций.
Я сам часто использую подсчет количества итераций в самом цикле:) Но если бы вместо подсчета размера массива ограничителем числа итераций стояла самописная трудозатратная функция, я бы либо оптимизировал саму функцию. либо ее результат посчитал заранее. :)
Про итерации я и написал, что прирост можно ощутить только на большом количестве итераций. Я старался сильно отталкиваться от опыта разработки, и что перевешивает в данном случае важнее — удобство, читабельность, подддержка кода или оптимизация. Там приведены тесты, и само собой на большом количестве итераций.
Я сам часто использую подсчет количества итераций в самом цикле:) Но если бы вместо подсчета размера массива ограничителем числа итераций стояла самописная трудозатратная функция, я бы либо оптимизировал саму функцию. либо ее результат посчитал заранее. :)
У меня просто сложилось ощущение, что вы слишком много думаете над вещами, которые этого не стоит;) Когда я получаю прирост производительности порядка 400% от включения оптимизатора, адекватного кеширования и правильной настройки сервера, то 5-10%, которые я выиграю от скурпулезной оптимизации кода, меня все равно не спасут. Но времени я затрачу на это гораздо больше, чем на первые мероприятия.
Я не думаю о таких вещах:) Просто решил, что написать это будет интересно :)
Процесс происходил примерно так: на прошлой недели я парсил англоязычные ресурсы по веб разработке, и наткнулся на эту статью. Мне она показалась местами интересной,, но в тоже время сразу появилось много мыслей, протестующих против такой оптимизацией, и также мысли взвешивающие ее смысл. И решил изложить эти мысли. Что имеет смысл оптимизировать, что нет, и когда. И каким образом.
Сам я не занимаюсь оптимизацией до того момента пока проект не запущен.
Больше всего внимание уделяю архитектуре(иногда до фанатизма, и забываю о любой оптимизации:) ), удобству использования API, периодически вспоминаю принципы agile dev, и чтобы все строилось на шаблонах :) Уделяю много внимания читаемости кода, и документированию проекта.
Процесс происходил примерно так: на прошлой недели я парсил англоязычные ресурсы по веб разработке, и наткнулся на эту статью. Мне она показалась местами интересной,, но в тоже время сразу появилось много мыслей, протестующих против такой оптимизацией, и также мысли взвешивающие ее смысл. И решил изложить эти мысли. Что имеет смысл оптимизировать, что нет, и когда. И каким образом.
Сам я не занимаюсь оптимизацией до того момента пока проект не запущен.
Больше всего внимание уделяю архитектуре(иногда до фанатизма, и забываю о любой оптимизации:) ), удобству использования API, периодически вспоминаю принципы agile dev, и чтобы все строилось на шаблонах :) Уделяю много внимания читаемости кода, и документированию проекта.
да конечно интересно — это база для начального уровня программирования без нее нельзя. Иначе это будет как если начало обучения в автошколе начинать с того как нужно с ментами торговаться о взятках
да конечно интересно — это база для начального уровня программирования без нее нельзя. Иначе это будет как если начало обучения в автошколе начинать с того как нужно с ментами торговаться о взятках
В оригинале есть про использование eAccelerator, Memcached. Не дошел до этого.
ага особенно прикольно когда цикл по SQL выборке идет и внутри каждой итерации query('SELECT count(*)...') а ведь все это имеет одну природу — не понимание процесса. Научитесь следовать интуитивно оптимизации в малом — будите чувствовать узкие места в большом
>>ага особенно прикольно когда цикл по SQL выборке идет и внутри каждой итерации query('SELECT count(*)...')
Ага, я имел ввиду как раз подобные трудозатратные функции.
Но того на практике не приходилось встречать.
Да, когда понимаешь хорошо сам процесс, то уже не делаешь подобных ошибок. Вообще для чистоты программирования лучше не использовать свои собственные функции в циклах for для ограничения числа итераций. Иначе изменение кода такой функции может повлечь непредсказуемые последствия.
Ага, я имел ввиду как раз подобные трудозатратные функции.
Но того на практике не приходилось встречать.
Да, когда понимаешь хорошо сам процесс, то уже не делаешь подобных ошибок. Вообще для чистоты программирования лучше не использовать свои собственные функции в циклах for для ограничения числа итераций. Иначе изменение кода такой функции может повлечь непредсказуемые последствия.
По поводу пункта 4. Как-то тут же проскакивала ссылка на phpbench.com/ там есть следующая статистика:
1. echo 'aaaaaaa'.'aaaaaaa'.'aaaaaaa'.'aaaaaaa' — Total time: 117 µs
2. echo 'aaaaaaa','aaaaaaa','aaaaaaa','aaaaaaa' — Total time: 300 µs
Но опять же:
1. $a = 'aaaaaaa';
echo $a.$a.$a.$a — Total time: 412 µs
2. $a = 'aaaaaaa';
echo $a,$a,$a,$a — Total time: 371 µs
Поэтому советы надо еще проверять и проверять.
1. echo 'aaaaaaa'.'aaaaaaa'.'aaaaaaa'.'aaaaaaa' — Total time: 117 µs
2. echo 'aaaaaaa','aaaaaaa','aaaaaaa','aaaaaaa' — Total time: 300 µs
Но опять же:
1. $a = 'aaaaaaa';
echo $a.$a.$a.$a — Total time: 412 µs
2. $a = 'aaaaaaa';
echo $a,$a,$a,$a — Total time: 371 µs
Поэтому советы надо еще проверять и проверять.
> 8. По возможности используйте require() вместо require_once(). [статья]
Может быть вы наоборот хотели написать?
Использовать require_once() вместо require()? Да, и ссылка в 8-ом пункте идет туда же, куда в 9-ятом. Хотя там совсем не о require/require_once говорится, а об абсолютных и относительных путях.
Может быть вы наоборот хотели написать?
Использовать require_once() вместо require()? Да, и ссылка в 8-ом пункте идет туда же, куда в 9-ятом. Хотя там совсем не о require/require_once говорится, а об абсолютных и относительных путях.
Вы будете писать 5 топиков про это, что выложили только 10 из 50? :)
Нет, буду просто указывать номера:)
Конечно, хотелось все написать в один пост, но получилось бы слишком много, да и не находится сразу такого количества времени. А просто перевод делать не хотел, потому что с одной стороны статья показалась интересной, с другой стороны во многом с ней не согласен. И поэтому наоборот в своих комментариях к ней не призываю делать как там написано, а задуматься о осмысленности сих действий, основываясь на своих знаниях и опыте. Плюс постараюсь добавить любую конструктивную критику в пост.
Конечно, хотелось все написать в один пост, но получилось бы слишком много, да и не находится сразу такого количества времени. А просто перевод делать не хотел, потому что с одной стороны статья показалась интересной, с другой стороны во многом с ней не согласен. И поэтому наоборот в своих комментариях к ней не призываю делать как там написано, а задуматься о осмысленности сих действий, основываясь на своих знаниях и опыте. Плюс постараюсь добавить любую конструктивную критику в пост.
Байтоптимизация — зло.
Оптимизировать надо то, что действительно нуждается в оптимизации.
Оптимизировать надо то, что действительно нуждается в оптимизации.
Да, я знаю:) Хотя бы потому что имел опыт работы с людьми, кто был помешан на такой оптимизации, и достаточно намучался. Но я решил дать критику каждому совету в этой статье на основе своего опыта разработки. И добавил вначале что не призываю ими пользоваться, а рассмотриваюсмысл каждого в отдельности.
Не всегда зло, если, например, говорить об оптимизации кода в циклах.
По поводу __autoload(). Слышал, что он медленнее, чем использование spl_autoload_registry().
а еще spl-евский автолоадер удобнее, что все таки на вход принимает каллбэк
Экономия на спичках
зависит от размеров проекта и количества денег на сервера.
где то из спичек можно и дом построить.
где то из спичек можно и дом построить.
Из-за попытки «соптимизировать» код, следуя вышеизложенным советам, велик шанс упустить реальные дыры в производительности.
Да. Но можно ли считать неверным мнение, если не аргументировать, почему оно не верно.
ну. не надо сильно заморачиваться на момент разработки об оптимизации. просто пишешь имея определенное представление об оптимизации.
А уже по выполнении основной части задач, когда разработана основная часть, можно подумать и об этих спичках. Тестировать на скрипты на узкие места, и устранять их
А уже по выполнении основной части задач, когда разработана основная часть, можно подумать и об этих спичках. Тестировать на скрипты на узкие места, и устранять их
привет, и ты решил в это гиблое дело «холивора о спичечной оптимизации» ввязаться :-)
Не поймёшь этих оптимизаторов: то print быстрее echo, потому что echo это, мол, макрос для вызова того же print, то как в этой статье echo быстрее.
оптимизировать надо алгоритмы, прирост куда более существенный
Единственное, что тут разумно — это совет не вычислять count в цикле. Всё остальное — мусор, на обсуждение которого тратится 90% времени в ньюбовских форумах и который не оказывает ВООБЩЕ НИКАКОГО влияния на реальную разработку.
Если остальные 40 «советов» того же качества, то не надо их переводить, пожалуйста.
Если остальные 40 «советов» того же качества, то не надо их переводить, пожалуйста.
>> совет не вычислять count в цикле
ну так этот совет я ещё на примере паскаля помню.
ну так этот совет я ещё на примере паскаля помню.
С паскалем понятно. Но разве это нужно в современных высокоуровневых языках? Или count вручную каждый раз длину массива высчитывает?
каждый раз. где гарантия что размер массива у вас не меняется в процессе работы цикла, раз вы count втыкаете в цикл?
или вы об оптимизациях? мол следить за тем, изменился ли массив или нет? это слишком накладно, и реализуется разве только самим программистом в ооп.
или вы об оптимизациях? мол следить за тем, изменился ли массив или нет? это слишком накладно, и реализуется разве только самим программистом в ооп.
Вообще условие это проверяется на каждой итерации цикла… Поэтому…
Вообще я сомневаюсь что разработчики не учли этот момент и не с оптимизировали его. Операция по вычислению длины массива при удалении и добавлении элементов из него гораздо быстрее, чем пересчет длины массива каждый раз. Как мне утверждали люди, кто ковырял исходники PHP(на сходке PHPClub), для строк длина хранится в служебной таблице. Скорей всего также и для массивов. А время отнимает сам вызов функции, который медленней, чем извлечение значения переменной.
Это мои предположения, как «должно быть». Планирую поковырять исходники интереса ради, очень любопытно стало.
Это мои предположения, как «должно быть». Планирую поковырять исходники интереса ради, очень любопытно стало.
Не сомневайтесь, это действительно так. Иначе бы мы врядли могли работать с «плавающим» условием в циклах, в качетсве примера даже набросал вам такой вот код:
при выводе получил:
float 0.24206590652466
float 0.002018928527832
$testArray = array_fill(0, 10000, rand(0, 255));
$start = xdebug_time_index();
for($i = 0; $i < count($testArray); $i++) {
;
}
var_dump(xdebug_time_index() - $start);
$start = xdebug_time_index();
for($i = 0, $c = count($testArray); $i < $c; $i++) {
;
}
var_dump(xdebug_time_index() - $start);
при выводе получил:
float 0.24206590652466
float 0.002018928527832
Вот и я так думал. Но судя по предыдущему комментарию, это не так.
С паскалем то все ястно, он компилируемый, впринципе если компилятор у языка хороший, то вот такие лаги как вызов каунта на каждой итерации, компилятор сам разрешает, что врядли можно отнести к интерпретируемым языкам. вроде пыха, хотя это только предположение, не знаю как там с пыхом, может в момент трансляции в опкод он еще ченить там и оптимизирует
Как вы объясните то, что существуют довольно опытные разработчики, которые при этом часто стараются экономить на спичках?
Работа над таким проектом из-за ужасности кода растягивается в разы. Например я встречал экономию, когда люди не писали перменные, имена методов, функций, классов длиннее 8 символов, потому что имена длиннее 8 символов тормозят выполнение кода. (как я помню это было в PHP4 и ниже, и касалось только переменных).
Работа над таким проектом из-за ужасности кода растягивается в разы. Например я встречал экономию, когда люди не писали перменные, имена методов, функций, классов длиннее 8 символов, потому что имена длиннее 8 символов тормозят выполнение кода. (как я помню это было в PHP4 и ниже, и касалось только переменных).
count НЕ вычисляется. количество элементов массива хранится во внутренней переменной. count просто возвращает её значение.
Да это уже и не важно. В одном случае у нас статическая проверка переменной, в другой — дергаем функцию. На низком уровне операции по затратам ресурсов отличаются в разы. Что при большом количестве итераций дает о себе знать.
А некоторые считают что оно вычисляется так вовсе один раз, и в проверке дерается непойми что — в итоге получаются цыклы которые кладут вообще всю систему на несколько секунд.
А некоторые считают что оно вычисляется так вовсе один раз, и в проверке дерается непойми что — в итоге получаются цыклы которые кладут вообще всю систему на несколько секунд.
Какой можете дать совет по этому вопросу:
оптимальней не использовать логическое отрицание в условиях или разница в вычислениях совершенно не значительна? То есть из приведенных ниже примеров кода — первый будет быстрее, или без разницы?
1.
if ($x) {
y()
} else {
z()
}
2.
if (!$x) {
z()
} else {
y()
}
оптимальней не использовать логическое отрицание в условиях или разница в вычислениях совершенно не значительна? То есть из приведенных ниже примеров кода — первый будет быстрее, или без разницы?
1.
if ($x) {
y()
} else {
z()
}
2.
if (!$x) {
z()
} else {
y()
}
Хм… Первый работает быстрее. В любом случае $x приводится к bool. Но во втором случае делается дополнительная операция отрицания.
Я делаю обычно тот блок кода, который должен выполняться чаще выше. И привык к этому.
Но в последнее время я для удобства часто использую исключения для ошибочных ситуаций, и выхода из них. И конструкции if else, if-elseif else встречаются редко.
Гораздо чаще в функциях встречается подобное:
if(..) {
…
return $res1;
}
return $res2;
Я делаю обычно тот блок кода, который должен выполняться чаще выше. И привык к этому.
Но в последнее время я для удобства часто использую исключения для ошибочных ситуаций, и выхода из них. И конструкции if else, if-elseif else встречаются редко.
Гораздо чаще в функциях встречается подобное:
if(..) {
…
return $res1;
}
return $res2;
думаю нет разницы, так как на низшем уровне например в машинных кодах, есть jz(jump zero) и jnz(jump not zero), которые выполняются одинаково по скорости, а проверка на ноль — с помощью одной и той же команды «test a,b»
ну это так в ассемблере, в пхп думаю аналогично
ну это так в ассемблере, в пхп думаю аналогично
п.5:
for ($x=0; $x < count($array); $x),
может все же for ($x=0; $x < count($array); ++$x)?
Но по мне лучше вообще вот так:
for ($x=0; $x < count($array); $x),
может все же for ($x=0; $x < count($array); ++$x)?
Но по мне лучше вообще вот так:
for ($x = 0, $l = count($array); $x < $l; ++$x) {...}
Эти советы кочуют из года в год начиная с 90-х годов, из форума в форум, одно да потому. А про count вообще молчу… Создайте уже кто-нибудь hellophp.ru (домен свободен) и накидайте уже подобных умозаключений хоть по самую крышку, зачем на 50 форумах одно и тоже обсасывать? :) Извиняюсь, если обидел светлые чувства.
>для него было бы наглядней прямые инклуды, чем использование __autoload(),
Значит он еще нуб.
Значит он еще нуб.
В 99,9% случаев оптимизировать надо БД, поскольку она является основным «тормозом» (проставить индексы, проанализировать запросы, переписать джойны и т.д.). В остальных 0,01% случаев (часто при работе с большими объемами данных) эти оптимизации действительно спасают. Был у меня случай, когда надо было оптимизировать скрипт, который разбирал и анализировал бинарный файл, так после вот такой «экономии на спичках» объем памяти, занимаемой скриптом во время работы, сократился с 150Мб до 12Мб, а время работы уменьшилось в 4 раза!
ну уж обработку бинарного файла стоит переложить с сил php, perl на c.
Уж не думаю, что такой прирост у вас случился если вы изменили с print-а на echo и перестали использовать __autoload. Думаю как раз по мелочи вы и оптимизировали алгоритм.
Ну, в основном, оптимизация состояла из обнулений переменных, выносов однотипных расчетов из циклов (типа того же count), реюз переменных, ну и один кусок в сотню с лишним строк был полностью отрефакторен (правда чем он мне тогда не понравился я уже и не помню :) )
выносов однотипных расчетов из циклов (типа того же count) — уже достаточно для того, что бы в некоторых случаях сократить количество потребляемых ресурсов в несколько раз.
да и полный рефакторинг куска в сотню с лишним строк — в оптимизации понятие расплывчатое. После него можно было и в десятки раз замедлить алгоритм так и в десятки раз его ускорить
да и полный рефакторинг куска в сотню с лишним строк — в оптимизации понятие расплывчатое. После него можно было и в десятки раз замедлить алгоритм так и в десятки раз его ускорить
Мне кажется, что гораздо круче получить 300% к читаемости и расширяемости, чем 0.0001% к производительности.
Особенно если учесть, что производительность дешево и быстро наращивается докупкой аренды серверов, котрорые стоят НА ПОРЯДОК дешевле зарплаты программиста.
Существуют вещи, которые не снижают читабельность кода, но повышают пусть, и незначительно производительность. Их просто относят к хорошему тону программирования. Не официально.
Не каждое приложение можно кластеризировать, если это не продумано в архитектуре… А если на работающем приложении можно повысить производительность, оптимизировав его, и по трудозатратам это окупаемо, то почему бы не сделать это.
Не каждое приложение можно кластеризировать, если это не продумано в архитектуре… А если на работающем приложении можно повысить производительность, оптимизировав его, и по трудозатратам это окупаемо, то почему бы не сделать это.
> Не каждое приложение можно кластеризировать, если это не продумано в архитектуре…
Роутим запрос на менее загруженный сервер, при этом все сервера работают с единой БД(кластер).
До определенного момента будет расширяемо. Вот когда этот предел будет близко — тогда надо думать об оптимизации. Но таких проектов в интернете не так уж и много =)
Роутим запрос на менее загруженный сервер, при этом все сервера работают с единой БД(кластер).
До определенного момента будет расширяемо. Вот когда этот предел будет близко — тогда надо думать об оптимизации. Но таких проектов в интернете не так уж и много =)
Если проект выбивается из рамок одного сервера — то здесь уже однозначно надо думать об оптимизации. Это уже другой уровень.
В своё время я работал в одном крупном магазинев котором стоял сервер Oracle, и вот эта «дура» съедала на себя очень много железок, а всё потому что когда-то софт был написан не особо дальновидными программмистами для небольшой фирмы. Фирма значительно разрослась, программисты ушли, а софтина осталась та-же, неоптимизированная.
В своё время я работал в одном крупном магазинев котором стоял сервер Oracle, и вот эта «дура» съедала на себя очень много железок, а всё потому что когда-то софт был написан не особо дальновидными программмистами для небольшой фирмы. Фирма значительно разрослась, программисты ушли, а софтина осталась та-же, неоптимизированная.
Даже если отвлечься от общей бессмысленности данного направления исследований, большинство из этих пунктов бессмысленны по своему.
Нельзя никогда абсолютно точно говорить о том, что один из вариантов лучше другого. В одном случае один лучше, а в другом другой.
Нельзя никогда абсолютно точно говорить о том, что один из вариантов лучше другого. В одном случае один лучше, а в другом другой.
Статья взята за основу. Я привел аргументы в пользу или во вред каждого из советов + свой опыт, и составил рекомендации, как не делать грубых ошибок по теме оптимизации.
Вы сделали очень много грубых ошибок.
Пример: «Скорей всего это по причине того, что если использовать sprintf, то PHP обращается к С-функции sprintf. Что само собой быстрее чем если разбор строки будет производить сам PHP, написанный на С.»
«Скорее всего», это не опыт. Это предположение ниочём на основании ничего.
Так кто же всё-таки будет разбирать? PHP или тот же C на котором он написан? А sprintf не разбирает строку?
А поток вывода это открытый космос, в который просто выкидывают строки? Чем вывод в него быстрее конкатентации? А что знаете про оптимизацию строковых функций в ядре PHP? В нём приёмы по оптимизации работы со строками из других языков не действуют.
Не будем разбирать всё это. Я не об этом.
Я о том, что нельзя про каждый пункт говорить так уверено и на все случаи жизни. Можно только рассматривать применение в каждом возможном варианте.
А если я хочу два раза подключить файл? require_once мне помешает. А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
А по поводу echo vs print говорить уже надоело.
Пример: «Скорей всего это по причине того, что если использовать sprintf, то PHP обращается к С-функции sprintf. Что само собой быстрее чем если разбор строки будет производить сам PHP, написанный на С.»
«Скорее всего», это не опыт. Это предположение ниочём на основании ничего.
Так кто же всё-таки будет разбирать? PHP или тот же C на котором он написан? А sprintf не разбирает строку?
А поток вывода это открытый космос, в который просто выкидывают строки? Чем вывод в него быстрее конкатентации? А что знаете про оптимизацию строковых функций в ядре PHP? В нём приёмы по оптимизации работы со строками из других языков не действуют.
Не будем разбирать всё это. Я не об этом.
Я о том, что нельзя про каждый пункт говорить так уверено и на все случаи жизни. Можно только рассматривать применение в каждом возможном варианте.
А если я хочу два раза подключить файл? require_once мне помешает. А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
А по поводу echo vs print говорить уже надоело.
php — opensource. автор может посмотреть код и сказать нам точно =)
>>Я о том, что нельзя про каждый пункт говорить так уверено и на все случаи жизни. Можно только рассматривать применение в каждом возможном варианте.
Я приводил рекомендации. И ситуации. На echo vs print внимание не заострял. Как раз задачей я ставил не показать что это быстрее этого, и надо делать так, а что пусть это и быстрее этого, но от этого код лучше не станит, и это глупая экономия.
Поток вывода — обобщил. Если подскажите как написать лучше, исправлю. PHP может отправлять данные в стандартный поток вывода, если работа скрипта идет в консоли, а может передавать apache'у. И разница скорей всего есть.
Анализ исходного кода может занять много времени, более быстрое решение тесты в различных условиях. У меня есть желание поковырять ядро PHP, но пока не дошли руки :)
Внимание я старался заострять на тех вопросах, которые могут повысить производительность при определенных условиях.
>>А если я хочу два раза подключить файл? require_once мне помешает. А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я строил статью как рассмотрение советов в оригинальной статье. И не писал, что во всех случаях надо обязательно применять require_once.
>>А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я не обязываю делать так всегда. Для целостных проектов это удобно. Для отдельной библиотеки действительно нет смысла.
Как я помню, многие наборы классов на phpclasses.org, если это набор классов, а не одиночный, не имеют инклудов друг на друга, есть файл примера, где они все инклудятся.
Я приводил рекомендации. И ситуации. На echo vs print внимание не заострял. Как раз задачей я ставил не показать что это быстрее этого, и надо делать так, а что пусть это и быстрее этого, но от этого код лучше не станит, и это глупая экономия.
Поток вывода — обобщил. Если подскажите как написать лучше, исправлю. PHP может отправлять данные в стандартный поток вывода, если работа скрипта идет в консоли, а может передавать apache'у. И разница скорей всего есть.
Анализ исходного кода может занять много времени, более быстрое решение тесты в различных условиях. У меня есть желание поковырять ядро PHP, но пока не дошли руки :)
Внимание я старался заострять на тех вопросах, которые могут повысить производительность при определенных условиях.
>>А если я хочу два раза подключить файл? require_once мне помешает. А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я строил статью как рассмотрение советов в оригинальной статье. И не писал, что во всех случаях надо обязательно применять require_once.
>>А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я не обязываю делать так всегда. Для целостных проектов это удобно. Для отдельной библиотеки действительно нет смысла.
Как я помню, многие наборы классов на phpclasses.org, если это набор классов, а не одиночный, не имеют инклудов друг на друга, есть файл примера, где они все инклудятся.
Добавлю.
Я рассчитывал на продуктивное обсуждение. Я могу гдето ошибаться, гдето чтото не учесть.
Сейчас я сомневаюсь, стоит ли описывать остальные 40 советов. Но если стоит, то в другом стиле, с другим подходом, с акцентированием внимания на стоящие вещи, и с большей конретикой. Или точным указанием что это мнение основанное на моем опыте, или конкретный пример.
Я рассчитывал на продуктивное обсуждение. Я могу гдето ошибаться, гдето чтото не учесть.
Сейчас я сомневаюсь, стоит ли описывать остальные 40 советов. Но если стоит, то в другом стиле, с другим подходом, с акцентированием внимания на стоящие вещи, и с большей конретикой. Или точным указанием что это мнение основанное на моем опыте, или конкретный пример.
50+ советов, которые вы уже не раз читали, и теперь читаете только из-за комментариев.
Вы считаете что их все читали? Я сначала нашел эту статью, потом поискал на хабре аналогичные. Нашел перевод 40 советов, и выложил на них ссылку вначале статьи. Но тема там не была разрешена. Стоит делать или не стоит, поэтому решил развернуть тему, и сделать попытку закрыть ее. А за основу взял статью про 50 советов. Чтобы было от чего отталкиваться.
Спасибо, буду ждать остальное…
Ух ты, опять мусолим эхо и принт. Я так соскучился ^_^
Вот по поводу __set, __get, __call несоглашусь, оно конечно подтомаживает, но это плата за удобство, и вполне разумная. Если конечно их испльзование оправдано. Например порой довольно удобно делать автоподгрузку класса при вызове его метода вроде этого $API->Users->get($id); соотв. в __get подключаем класс, создаем и возвращаем объект, и тут как раз автолоад пригодится может для большей прозрачности. И кстати тормоза большого это не дает.
Вот по поводу __set, __get, __call несоглашусь, оно конечно подтомаживает, но это плата за удобство, и вполне разумная. Если конечно их испльзование оправдано. Например порой довольно удобно делать автоподгрузку класса при вызове его метода вроде этого $API->Users->get($id); соотв. в __get подключаем класс, создаем и возвращаем объект, и тут как раз автолоад пригодится может для большей прозрачности. И кстати тормоза большого это не дает.
Как-то уже была подобная статья на Хабре. Там же были комментарии про отсутствие необходимости в оптимизации подобных «мелочей».
в большинстве своём советы идиотские, лучше не запоминайте.
потому что оптимизировать нужно не что попало, а то, что тормозит.
«хорошо» не обязательно сочетается с вышеозвученными советами.
большинство из них идут вразрез с CC в ваших проектах/вашими предпочтениями => следование этим советам замедлит написание и усложнит понимание привычных конструкций.
стоят ли выйгранные 0.1% этого, при том что настоящая оптимизация даёт выйгрыши на порядки больше.
также, насколько я понимаю, опыта серьёзных оптимизаций у вас нет, и вы ещё не поняли, что академически стройный и оптимальный код — две крайности. и начинать стоит с первой. почему?
потому что качественный код:
1. проще развивать.
2. проще поддерживать.
3. проще оптимизировать.
и это я ещё не уточнил про надуманность и откровенную глупость во фразах вроде:
«5. Не используйте вычисления числа элементов массива, длины строки и т.п., для определения последней итерации цикла в самом цикле. Установите максимальное значение для цикла for перед ним. Например: for ($x=0; $x < count($array); $x), вызывает count() при каждой итерации, используйте $max=count($array); перед циклом. ссылка [тест]
Это давно известный факт. Тест показывает разницу в производительности в 10 раз. Если имеет место довольно большой массив данных, или подобные вычисления происходят часто, стоит задуматься. На читабельность не влияет никак. „
откуда взялось “в 10 раз»? т.е. время работы часового алгоритма, который расположен в теле цикла, сократится до 6 минут, если изменить count на переменную? да? :-)
большинство из них идут вразрез с CC в ваших проектах/вашими предпочтениями => следование этим советам замедлит написание и усложнит понимание привычных конструкций.
стоят ли выйгранные 0.1% этого, при том что настоящая оптимизация даёт выйгрыши на порядки больше.
также, насколько я понимаю, опыта серьёзных оптимизаций у вас нет, и вы ещё не поняли, что академически стройный и оптимальный код — две крайности. и начинать стоит с первой. почему?
потому что качественный код:
1. проще развивать.
2. проще поддерживать.
3. проще оптимизировать.
и это я ещё не уточнил про надуманность и откровенную глупость во фразах вроде:
«5. Не используйте вычисления числа элементов массива, длины строки и т.п., для определения последней итерации цикла в самом цикле. Установите максимальное значение для цикла for перед ним. Например: for ($x=0; $x < count($array); $x), вызывает count() при каждой итерации, используйте $max=count($array); перед циклом. ссылка [тест]
Это давно известный факт. Тест показывает разницу в производительности в 10 раз. Если имеет место довольно большой массив данных, или подобные вычисления происходят часто, стоит задуматься. На читабельность не влияет никак. „
откуда взялось “в 10 раз»? т.е. время работы часового алгоритма, который расположен в теле цикла, сократится до 6 минут, если изменить count на переменную? да? :-)
хе :-) не ожидал, что вы согласитесь с моей точкой зрения так быстро.
users.livejournal.com/_adept_/62484.html
вот вам маленькая жизненная история в тему от очень хорошего разработчика.
users.livejournal.com/_adept_/62484.html
вот вам маленькая жизненная история в тему от очень хорошего разработчика.
Тест по ссылке для for показывает там разницу в 10 раз. И все, просто прокомментировал.
Т.е. Вы считаете что на то как написаны циклы, и какие конструкции в них используются не стоит обращать внимания вообще?
Некоторых совсем глупых вещей, таких как запросы к базе в циклах следует не делать и на написании кода.
Если же на работающем приложении возникают проблемы с производительностью, но были соптимизированы узкие места, такие как база данных, я думаю, стоит обратить внимание на циклы, где происходят сложные вычисления, с большим количеством итераций.
Как вы собрались анализировать производительность, кроме как на тестах? там абстрактные тесты. На реальных приложениях могут быть другие цифры.
Но методики от этого не меняются, и если все знают, что узкое место всегда основное база данных, как правило, то впервую очередь обращают внимание на ее оптимизацию.
Функция sprintf в php к примеру это обертка вокруг С-функции vpsprintf(). Но как работает vsprintf надо тоже разбираться. Но есть ли смысл.
Я специально сразу после ката написал что я как раз рекомендую не пользоваться этими советами. И статья не посвящена тому как оптимизировать PHP приложения от А до Я. А как раз посвящена всяким мелочам, и стоит ли на них обращать внимание или нет.
Т.е. Вы считаете что на то как написаны циклы, и какие конструкции в них используются не стоит обращать внимания вообще?
Некоторых совсем глупых вещей, таких как запросы к базе в циклах следует не делать и на написании кода.
Если же на работающем приложении возникают проблемы с производительностью, но были соптимизированы узкие места, такие как база данных, я думаю, стоит обратить внимание на циклы, где происходят сложные вычисления, с большим количеством итераций.
Как вы собрались анализировать производительность, кроме как на тестах? там абстрактные тесты. На реальных приложениях могут быть другие цифры.
Но методики от этого не меняются, и если все знают, что узкое место всегда основное база данных, как правило, то впервую очередь обращают внимание на ее оптимизацию.
Функция sprintf в php к примеру это обертка вокруг С-функции vpsprintf(). Но как работает vsprintf надо тоже разбираться. Но есть ли смысл.
Я специально сразу после ката написал что я как раз рекомендую не пользоваться этими советами. И статья не посвящена тому как оптимизировать PHP приложения от А до Я. А как раз посвящена всяким мелочам, и стоит ли на них обращать внимание или нет.
верно. там абстрактные тесты. абстрактные тесты дают абстрактные цифры. абстрактные цифры ни о чём не говорят.
повторю: хочешь написать статью об оптимизации — пиши о профайлерах, а не о спичечной экономии.
«Я специально сразу после ката написал что я как раз рекомендую не пользоваться этими советами.»
смысл тогда переводить статью, советам из которой ты призываешь не следовать?
«я тут перевёл статью, но практической пользы от советов в ней — никакой. более того, советую не следовать этим советам.»
повторю: хочешь написать статью об оптимизации — пиши о профайлерах, а не о спичечной экономии.
«Я специально сразу после ката написал что я как раз рекомендую не пользоваться этими советами.»
смысл тогда переводить статью, советам из которой ты призываешь не следовать?
«я тут перевёл статью, но практической пользы от советов в ней — никакой. более того, советую не следовать этим советам.»
>>смысл тогда переводить статью, советам из которой ты призываешь не следовать?
Я мог ее и не переводить, и вставлять советы на родном языке. Но читать это было бы мене удобно.
Я написал статью в которую критикую эти советы, потому что надеюсь что людей, кто следует им станет меньше.
Я мог ее и не переводить, и вставлять советы на родном языке. Но читать это было бы мене удобно.
Я написал статью в которую критикую эти советы, потому что надеюсь что людей, кто следует им станет меньше.
«Если же на работающем приложении возникают проблемы с производительностью, но были соптимизированы узкие места, такие как база данных, я думаю, стоит обратить внимание на циклы, где происходят сложные вычисления, с большим количеством итераций.»
человеку, у которого в коде самым узким местом будет выбор «переменная или вызов функции в for()» я буду поклоняться, честно :-)
человеку, у которого в коде самым узким местом будет выбор «переменная или вызов функции в for()» я буду поклоняться, честно :-)
Я написал, что после того как все казалось бы узкие места убраны, стоит произвести анализ кода еще раз, и попробовать произвести оптимизацию циклов и посмотреть даст ли это какой либо существенный рост производительности.
А процентов 5 для высоконагруженного приложения существенно.
И я не имею ввиду такие вещи как count(), а именно когда в циклах проводятся сложные вычисления.
А процентов 5 для высоконагруженного приложения существенно.
И я не имею ввиду такие вещи как count(), а именно когда в циклах проводятся сложные вычисления.
«и посмотреть даст ли это какой либо существенный рост производительности. „
не нужно действовать на авось. это программирование, а не гадание. нужно измерить каждый участок кода и оптимизировать самый медленный.
уверяю тебя — до состояния “count у меня самая медленная конструкция» у тебя (да и вообще у кого угодно) не дойдёт никогда.
и 5% это очень солидный результат. никакой из приведённых советов такого прироста даже рядом не даст на живом коде.
не нужно действовать на авось. это программирование, а не гадание. нужно измерить каждый участок кода и оптимизировать самый медленный.
уверяю тебя — до состояния “count у меня самая медленная конструкция» у тебя (да и вообще у кого угодно) не дойдёт никогда.
и 5% это очень солидный результат. никакой из приведённых советов такого прироста даже рядом не даст на живом коде.
Не стоит таким поклоняться. Помню когда учился, на прикладной математики, у одного из одногрупников вычисление какой-то форумы происходило примерно полминуты, хотя у других и пары секунд не занимало. А все потому, что человек в цикле каждую итерацию вычислял небольшую такую часть форумы, которая всеми остальными вычислялась до этого самого цикла. А итераций там было чуть больше десяти тысяч. Но это если брать студентов…
А так, в реальных проектах в форе встречал более-мелкие косяки, типа парсинга небольшого xml файла, или еще чего подобного — не слишком объеные вычисления, что бы стать узким местом, но все таки.
А так, в реальных проектах в форе встречал более-мелкие косяки, типа парсинга небольшого xml файла, или еще чего подобного — не слишком объеные вычисления, что бы стать узким местом, но все таки.
И везде одно и тоже, сравнение echo и print…
Для себя ничего нового не увидел. Спасибо
Для себя ничего нового не увидел. Спасибо
Странно, что в статье большинство пунктов — именно что экономия на спичках. А вот такие важные вещи, как:
— сокращайте число итераций во внутренних циклах: встроенная функция типа array_xxx() и т.д. лучше, чем цикл на 1 тыс. итераций,
— если массивы передаются в параметрах или копируются, после чего меняются, старайтесь сохранять их маленькими
— старайтесь не писать много PHP-кода, принцип KISS
даже не упоминаются. Например, экономия «конкатенация вместо интерполяции» тут меркнет на фоне любого вызова str_replace или preg_replace, которые, конечно же, есть почти в каждом мало-мальски сложном проекте.
— сокращайте число итераций во внутренних циклах: встроенная функция типа array_xxx() и т.д. лучше, чем цикл на 1 тыс. итераций,
— если массивы передаются в параметрах или копируются, после чего меняются, старайтесь сохранять их маленькими
— старайтесь не писать много PHP-кода, принцип KISS
даже не упоминаются. Например, экономия «конкатенация вместо интерполяции» тут меркнет на фоне любого вызова str_replace или preg_replace, которые, конечно же, есть почти в каждом мало-мальски сложном проекте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Серия 50+ советов по оптимизации PHP кода. «За» и «против» такой оптимизации. Первые 10 советов.