>>смысл тогда переводить статью, советам из которой ты призываешь не следовать?
Я мог ее и не переводить, и вставлять советы на родном языке. Но читать это было бы мене удобно.
Я написал статью в которую критикую эти советы, потому что надеюсь что людей, кто следует им станет меньше.
Я написал, что после того как все казалось бы узкие места убраны, стоит произвести анализ кода еще раз, и попробовать произвести оптимизацию циклов и посмотреть даст ли это какой либо существенный рост производительности.
А процентов 5 для высоконагруженного приложения существенно.
И я не имею ввиду такие вещи как count(), а именно когда в циклах проводятся сложные вычисления.
Тест по ссылке для for показывает там разницу в 10 раз. И все, просто прокомментировал.
Т.е. Вы считаете что на то как написаны циклы, и какие конструкции в них используются не стоит обращать внимания вообще?
Некоторых совсем глупых вещей, таких как запросы к базе в циклах следует не делать и на написании кода.
Если же на работающем приложении возникают проблемы с производительностью, но были соптимизированы узкие места, такие как база данных, я думаю, стоит обратить внимание на циклы, где происходят сложные вычисления, с большим количеством итераций.
Как вы собрались анализировать производительность, кроме как на тестах? там абстрактные тесты. На реальных приложениях могут быть другие цифры.
Но методики от этого не меняются, и если все знают, что узкое место всегда основное база данных, как правило, то впервую очередь обращают внимание на ее оптимизацию.
Функция sprintf в php к примеру это обертка вокруг С-функции vpsprintf(). Но как работает vsprintf надо тоже разбираться. Но есть ли смысл.
Я специально сразу после ката написал что я как раз рекомендую не пользоваться этими советами. И статья не посвящена тому как оптимизировать PHP приложения от А до Я. А как раз посвящена всяким мелочам, и стоит ли на них обращать внимание или нет.
Вообще я сомневаюсь что разработчики не учли этот момент и не с оптимизировали его. Операция по вычислению длины массива при удалении и добавлении элементов из него гораздо быстрее, чем пересчет длины массива каждый раз. Как мне утверждали люди, кто ковырял исходники PHP(на сходке PHPClub), для строк длина хранится в служебной таблице. Скорей всего также и для массивов. А время отнимает сам вызов функции, который медленней, чем извлечение значения переменной.
Это мои предположения, как «должно быть». Планирую поковырять исходники интереса ради, очень любопытно стало.
Я рассчитывал на продуктивное обсуждение. Я могу гдето ошибаться, гдето чтото не учесть.
Сейчас я сомневаюсь, стоит ли описывать остальные 40 советов. Но если стоит, то в другом стиле, с другим подходом, с акцентированием внимания на стоящие вещи, и с большей конретикой. Или точным указанием что это мнение основанное на моем опыте, или конкретный пример.
>>Я о том, что нельзя про каждый пункт говорить так уверено и на все случаи жизни. Можно только рассматривать применение в каждом возможном варианте.
Я приводил рекомендации. И ситуации. На echo vs print внимание не заострял. Как раз задачей я ставил не показать что это быстрее этого, и надо делать так, а что пусть это и быстрее этого, но от этого код лучше не станит, и это глупая экономия.
Поток вывода — обобщил. Если подскажите как написать лучше, исправлю. PHP может отправлять данные в стандартный поток вывода, если работа скрипта идет в консоли, а может передавать apache'у. И разница скорей всего есть.
Анализ исходного кода может занять много времени, более быстрое решение тесты в различных условиях. У меня есть желание поковырять ядро PHP, но пока не дошли руки :)
Внимание я старался заострять на тех вопросах, которые могут повысить производительность при определенных условиях.
>>А если я хочу два раза подключить файл? require_once мне помешает. А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я строил статью как рассмотрение советов в оригинальной статье. И не писал, что во всех случаях надо обязательно применять require_once.
>>А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я не обязываю делать так всегда. Для целостных проектов это удобно. Для отдельной библиотеки действительно нет смысла.
Как я помню, многие наборы классов на phpclasses.org, если это набор классов, а не одиночный, не имеют инклудов друг на друга, есть файл примера, где они все инклудятся.
Статья взята за основу. Я привел аргументы в пользу или во вред каждого из советов + свой опыт, и составил рекомендации, как не делать грубых ошибок по теме оптимизации.
Вы считаете что их все читали? Я сначала нашел эту статью, потом поискал на хабре аналогичные. Нашел перевод 40 советов, и выложил на них ссылку вначале статьи. Но тема там не была разрешена. Стоит делать или не стоит, поэтому решил развернуть тему, и сделать попытку закрыть ее. А за основу взял статью про 50 советов. Чтобы было от чего отталкиваться.
Существуют вещи, которые не снижают читабельность кода, но повышают пусть, и незначительно производительность. Их просто относят к хорошему тону программирования. Не официально.
Не каждое приложение можно кластеризировать, если это не продумано в архитектуре… А если на работающем приложении можно повысить производительность, оптимизировав его, и по трудозатратам это окупаемо, то почему бы не сделать это.
Хм… Первый работает быстрее. В любом случае $x приводится к bool. Но во втором случае делается дополнительная операция отрицания.
Я делаю обычно тот блок кода, который должен выполняться чаще выше. И привык к этому.
Но в последнее время я для удобства часто использую исключения для ошибочных ситуаций, и выхода из них. И конструкции if else, if-elseif else встречаются редко.
Как вы объясните то, что существуют довольно опытные разработчики, которые при этом часто стараются экономить на спичках?
Работа над таким проектом из-за ужасности кода растягивается в разы. Например я встречал экономию, когда люди не писали перменные, имена методов, функций, классов длиннее 8 символов, потому что имена длиннее 8 символов тормозят выполнение кода. (как я помню это было в PHP4 и ниже, и касалось только переменных).
Сам по себе да. Для PHP5 на различных серьезных ресурсах заявлялось что ООП код работает на 30% медленее процедурного. Но можно и без ооп, или просто используя неграмотно ООП технологии написать так, что будет исполняться медленней, чем при правильном применении ООП.
Плюс ООП подход ускоряет время самой разработки, и это себя хорошо оправдывает
Мне было бы интересно проверить, как появляют на скорость уже на работающем под нагрузкой приложении удаление больших ресурсов.
И еще интересный момент. Писался движок блогов(увы, все равно загнулся, из-за финансирования), после полного переписывания на ооп с разбиением на небольшие классы и с примением абстрактных фабрик,, простеньких контроллеров и небольших моделей, производительность выросла раза в 2 раза. Запросы не оптимизировались. Остальная часть — строилось на mysql + xslt шаблоны. На сервере по слухам, туда доступа у меня не было кроме фтп — memcached на апаче + nginx.
До этого серсис блогов, был написан таким образом, что классы просто использовались как контейнеры функций.
Я мог ее и не переводить, и вставлять советы на родном языке. Но читать это было бы мене удобно.
Я написал статью в которую критикую эти советы, потому что надеюсь что людей, кто следует им станет меньше.
А процентов 5 для высоконагруженного приложения существенно.
И я не имею ввиду такие вещи как count(), а именно когда в циклах проводятся сложные вычисления.
Т.е. Вы считаете что на то как написаны циклы, и какие конструкции в них используются не стоит обращать внимания вообще?
Некоторых совсем глупых вещей, таких как запросы к базе в циклах следует не делать и на написании кода.
Если же на работающем приложении возникают проблемы с производительностью, но были соптимизированы узкие места, такие как база данных, я думаю, стоит обратить внимание на циклы, где происходят сложные вычисления, с большим количеством итераций.
Как вы собрались анализировать производительность, кроме как на тестах? там абстрактные тесты. На реальных приложениях могут быть другие цифры.
Но методики от этого не меняются, и если все знают, что узкое место всегда основное база данных, как правило, то впервую очередь обращают внимание на ее оптимизацию.
Функция sprintf в php к примеру это обертка вокруг С-функции vpsprintf(). Но как работает vsprintf надо тоже разбираться. Но есть ли смысл.
Я специально сразу после ката написал что я как раз рекомендую не пользоваться этими советами. И статья не посвящена тому как оптимизировать PHP приложения от А до Я. А как раз посвящена всяким мелочам, и стоит ли на них обращать внимание или нет.
Это мои предположения, как «должно быть». Планирую поковырять исходники интереса ради, очень любопытно стало.
Но вообще с трудом верится, что аналитики провайдеров не смогли предсказать такой ситуации.
Я рассчитывал на продуктивное обсуждение. Я могу гдето ошибаться, гдето чтото не учесть.
Сейчас я сомневаюсь, стоит ли описывать остальные 40 советов. Но если стоит, то в другом стиле, с другим подходом, с акцентированием внимания на стоящие вещи, и с большей конретикой. Или точным указанием что это мнение основанное на моем опыте, или конкретный пример.
Я приводил рекомендации. И ситуации. На echo vs print внимание не заострял. Как раз задачей я ставил не показать что это быстрее этого, и надо делать так, а что пусть это и быстрее этого, но от этого код лучше не станит, и это глупая экономия.
Поток вывода — обобщил. Если подскажите как написать лучше, исправлю. PHP может отправлять данные в стандартный поток вывода, если работа скрипта идет в консоли, а может передавать apache'у. И разница скорей всего есть.
Анализ исходного кода может занять много времени, более быстрое решение тесты в различных условиях. У меня есть желание поковырять ядро PHP, но пока не дошли руки :)
Внимание я старался заострять на тех вопросах, которые могут повысить производительность при определенных условиях.
>>А если я хочу два раза подключить файл? require_once мне помешает. А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я строил статью как рассмотрение советов в оригинальной статье. И не писал, что во всех случаях надо обязательно применять require_once.
>>А если я подключаю файлы внутри библиотеки — мне нужны относительные пути, а не абсолютные…
Я не обязываю делать так всегда. Для целостных проектов это удобно. Для отдельной библиотеки действительно нет смысла.
Как я помню, многие наборы классов на phpclasses.org, если это набор классов, а не одиночный, не имеют инклудов друг на друга, есть файл примера, где они все инклудятся.
Не каждое приложение можно кластеризировать, если это не продумано в архитектуре… А если на работающем приложении можно повысить производительность, оптимизировав его, и по трудозатратам это окупаемо, то почему бы не сделать это.
Я делаю обычно тот блок кода, который должен выполняться чаще выше. И привык к этому.
Но в последнее время я для удобства часто использую исключения для ошибочных ситуаций, и выхода из них. И конструкции if else, if-elseif else встречаются редко.
Гораздо чаще в функциях встречается подобное:
if(..) {
…
return $res1;
}
return $res2;
Работа над таким проектом из-за ужасности кода растягивается в разы. Например я встречал экономию, когда люди не писали перменные, имена методов, функций, классов длиннее 8 символов, потому что имена длиннее 8 символов тормозят выполнение кода. (как я помню это было в PHP4 и ниже, и касалось только переменных).
Плюс ООП подход ускоряет время самой разработки, и это себя хорошо оправдывает
И еще интересный момент. Писался движок блогов(увы, все равно загнулся, из-за финансирования), после полного переписывания на ооп с разбиением на небольшие классы и с примением абстрактных фабрик,, простеньких контроллеров и небольших моделей, производительность выросла раза в 2 раза. Запросы не оптимизировались. Остальная часть — строилось на mysql + xslt шаблоны. На сервере по слухам, туда доступа у меня не было кроме фтп — memcached на апаче + nginx.
До этого серсис блогов, был написан таким образом, что классы просто использовались как контейнеры функций.