Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 215
Ох ща холивары-то начнутся.
Бро, это совсем и совсем неправильно. Ресурсы PHP масштабируются линейно добавлением серверов. Написать же базу (подразумеваем SQL), которую можно легко масштабировать добавлением сервером очень и очень геморно. Мало какой хайлоад проект джойны использует — не то, чтобы сложные запросы.
И это, добавь куда-нибудь в начало пунктики про использование оп-кешеров кода — APC, eAccelerator, XCache.
Использование сложных запросов к БД быстрее, чем использование нескольких простых
Использование вычислений на стороне СУБД быстрее, чем вычисления на стороне PHP для данных хранящихся в БД.
Бро, это совсем и совсем неправильно. Ресурсы PHP масштабируются линейно добавлением серверов. Написать же базу (подразумеваем SQL), которую можно легко масштабировать добавлением сервером очень и очень геморно. Мало какой хайлоад проект джойны использует — не то, чтобы сложные запросы.
И это, добавь куда-нибудь в начало пунктики про использование оп-кешеров кода — APC, eAccelerator, XCache.
Использование сложных запросов к БД быстрее, чем использование нескольких простых
Тоже в глаза бросилось. Не согласен с автором.
Да ну и вообще. За годы работы с PHP у меня сложилось мнение, что этот не тот язык, который надо оптимизировать. Ну это пустое занятие. Как правило, если появляются проблемы с сайтом, который, например, медленно работает, то это на 99 процентов не беда языка — это проблема архитектуры приложения и взаимодействия его компонентов.
Ну если уж вы попали в тот 1 процент — просто добавьте еще серверов. Они нынче такие дешевые.
Ну и, конечно же, не забываем Кнута:
Ну если уж вы попали в тот 1 процент — просто добавьте еще серверов. Они нынче такие дешевые.
Ну и, конечно же, не забываем Кнута:
«Преждевременная оптимизация — это корень всех бед»
Абсолютно согласен. Писать надо красиво, быстро — но без фанатизма. Ибо легче 100 руб за ресурсы доплатить, чем менять switch -и на if — ы.
Полностью согласен. Проблемы часто именно в архитектуре, кривых запросах и, как раз, сложных запросах, которые порой приходится переписывать на несколько простых, чтобы увеличить скорость. А вот оптимизация на спичках типа писать $var. ' text' вместо "$var text" давно уже считается экономией на спичках. В том же стандарте кодирования Zend сказано что если в строке встречаются одинарные кавычки, тов место записи 'some \'text\' ...' надо писать «some 'text' ...» ибо важнее читаемость кода и его дегкостьв отладке, чем такие оптимизации. Это частный случай, конечно, но все уже уже устал читать про такие оптимизации
У меня сложилось мнение, что 99 процентов это г@внозпросы к БД. Так что надо в первую очередь оптимизировать именно эту составляющую… И это не всегда переход к сложным запросам. Иногда, разбиение таковых на более мелкие и последующая группировка/сортировка и т.д. их на PHP. Как на одной конференции сказал представитель Бегуна, — «ресурсы PHP гораздо дешевле, чем MySQL» (в частности). Так что первый шаг, это переход на LazyLoad, IdentytiMap, UnitOfWork…
Ну а код должен быть понятным и читаемым ))
Бывают, конечно, и алгоритмические ошибки. Но это касается любого языка, а не только PHP.
Ну а код должен быть понятным и читаемым ))
Бывают, конечно, и алгоритмические ошибки. Но это касается любого языка, а не только PHP.
экономия на спичках
Мне кажется, у начинающих (для них же эта статья?) если что и тормозит, то это не PHP, а база.
А оптимизацией php надо заниматься уже на масштабах Facebook.
А оптимизацией php надо заниматься уже на масштабах Facebook.
Ну не скажите. Мы, например, выпускаем устройства с дохленьким arm-процессором, на котором кроме всего прочего крутится веб-админ на php. Приходится поневоле заниматься оптимизацией, чтобы странички по 30 секунд не генерились. :-)
жесть. другие языки, более легкие по ресурсам, не пробовали — типа lua?
К сожалению, интерпретатор PHP не может работать с ООП также быстро как с обычными функциями.
Понятное дело. Статья по «оптимизации», но надо добавить " скорости интерпретации и выполнения". Оптимизация разная бывает — может архитектурная, может лаконичности кода. И зачастую легче написать приложение, работающее в 2 раза медленнее чем эталон, но зато легко и быстро изменяемое. Если нужна скорость — ASM в помощь.
Я бы не сказал, что совет не использовать ООП — хороший :)
echo $var.«text» быстрее, чем echo "$var text"
Если нужно конкатенировать несколько переменных, то второй вариант как раз будет в плюсе по скорости, потому что у интерпретатора имеется возможность один раз выделить буфер под строку нужного размера, вместо выполнения цепочки пошаговых конкатенаций.
readfile быстрее, чем file_get_contents, file_get_contents быстрее, чем require, а require быстрее, чем include для вывода статического контента из отдельного файла
Жесть :)
О. Опять статья о том, что если утром встать с правой ноги, а не левой, то быстрее дойдёшь на работу.
прочитав заголовок, сделал предположение что статья о скорости кавычек и echo. Открыл — таки да, о них :)
«Так и вышло»
'Так и вышло'
?>так и вышло <?php
А вот за такое надо расстреливать без суда и следствия.
Вы приверженец вывода статики через echo или использования отличных от php шаблонизаторов? Расстреливать по-моему надо за echo 'так и вышло'.
Я приверженец монолитного кода и отделения логики от представления.
А логику представления куда денете?
$logic->replaсe('{result}','Так и вышло');
Это не значит, что я поддерживаю данный DLE и UMI подход.
Имеет право на жизнь, конечно, но мне кажется, что вынос статического текста из шаблона не есть хорошо. В шаблоне должны быть статические данные (разметка, «навигационные фразы» и т. п.) и логика представления (вывести столько строк таблицы, сколько в каком-то массиве), а «плейсхолдеры» заменяться на динамические из БД и файлов настроек, но ни в коем случае не на захардкоденные где-то в недрах приложения. Причина простая — такие данные должен быть способен изменить не программист, а или администратор сайта (динамические — через админку, бд или конфиги), или верстальщик (статические). Речь, конечно не идёт об, условно говоря, «коробочных» продуктах типа CMS, где настраиваться не программистом должно всё, но и там захардкоденные строки, имхо, исключены.
include('абсолютный путь') быстрее, чем include('относительный путь')
Дааам-с… И это в не значительные оптимизации?
Уважаемый, хоть тут и ежу понятно что абсолютный путь быстрее, а так же зависит от нескольких факторов, но по поводу её незначительности вы промазали ядерной боеголовкой +- пара тысячь километров. Если у вас include_path содержит хотя бы 3-4 папки и эти папки записаны в абы каком порядке (а я видал include_path по 7-12 папок), то потерять можно порядка 30% производительности. А штука вот в чём, когда относительный путь ищется, идёт проверка через stat каждой директории по порядку, а есть ли там чёртов файл, который надо подключить. И как вы думаете, сколько таких вызовов на КАЖДЫЙ подключаемый скрипт образуется? Возмите любой фреймворк где используется более-менее приличное кол-во компонент и поиграйтесь. Будете удивлены.
Кривой include_path — одна из тех злостных вещей, которая бъёт в самый центр. На ряду с кривой базой. Подтверждено личным опытом, когда оптимизировал один из проектов. strace просто с ума сходил от кол-ва stat вызовов, а системные вызовы как мы знаем очень дорогие. Оптимизация include-path + правильная расстановка относительных путей уже сильно спасает.
Так что я бы убрал из безполезных.
Когда начинается такая оптимизация на спичках — надо искать узкие места не кода, а алгоритма. Не поверю что алгоритм оптимизирован на все 100%! По поводу БД: 1-ая таблица — 5 млн. записей, 2-ая таблица — 8 млн. записей. Из первой возвращается 20 записей, из второй — ~60-80. На запрос по первичным ключам тратится около 0,0005 сек. На запрос с джойном — 1,5 секунд.
Товарищ — не думаю что цикл на 80 итераций займёт 1,5 секунд времени! Данный факт исследован, профилирован и вылизан до мелочей у нас на проекте.
Товарищ — не думаю что цикл на 80 итераций займёт 1,5 секунд времени! Данный факт исследован, профилирован и вылизан до мелочей у нас на проекте.
хаброрерайтеры настолько суровы, что указывают ссылки на исходный контент
"$row['id'] быстрее, чем $row[id]"
Тут надо указать, что второй способ вообще не рекомендуется применять, потому как у вас теоретически может быть задана константа с таким именем. Если в массиве ключи строковые, то их и записывать надо в виде строк.
Тут надо указать, что второй способ вообще не рекомендуется применять, потому как у вас теоретически может быть задана константа с таким именем. Если в массиве ключи строковые, то их и записывать надо в виде строк.
Это вредные советы?
А еще, замените все 'случаи' на 'случае', глаз режет. Аж 6 раз.
>preg _replace быстрее, чем ereg_replace, str_replace быстрее, чем preg_replace, но strtr быстрее, чем str_replace
Решил потестить насколько preg vs ereg в числах.
Получилось следующее (проводилось 100к иттераций в цикле).
Искалась строка в 3 статичных символа.
К примеру, большая строка (18200 байт), искаемого в ней нет:
preg 4.599s
ereg 6.959s
Такая же большая строка, искаемое есть в начале строки:
preg 0m5.045s
ereg 2m22.052s — тут конечнослив по полной.
Такая же большая строка, искаемое есть в конце строки:
preg 0m6.612s
ereg 3m10.676s — снова слив, вполне ожидаемый.
Урезаем строку до 64 байт. Искомое отсутствует:
preg 0m0.113s — 0m0.121s
ereg 0m0.123s — 0m0.123s
Видим не такой уж большой разрыв.
Снова строка 64 байт. Искомое присутствет в начале строки:
preg 0m0.131s — 0m0.140s
ereg 0m0.179s — 0m0.183s
Снова строка 64 байт. Искомое присутствет в конце строки:
preg 0m0.203s — 0m0.218s
ereg 0m0.494s — 0m0.503s
Регексп с патерном в 11 символов (в центре) по строке в 64 символа
preg 0m0.143s — 0m0.146s
ereg 0m0.647s — 0m0.664s
Решил потестить насколько preg vs ereg в числах.
Получилось следующее (проводилось 100к иттераций в цикле).
Искалась строка в 3 статичных символа.
К примеру, большая строка (18200 байт), искаемого в ней нет:
preg 4.599s
ereg 6.959s
Такая же большая строка, искаемое есть в начале строки:
preg 0m5.045s
ereg 2m22.052s — тут конечнослив по полной.
Такая же большая строка, искаемое есть в конце строки:
preg 0m6.612s
ereg 3m10.676s — снова слив, вполне ожидаемый.
Урезаем строку до 64 байт. Искомое отсутствует:
preg 0m0.113s — 0m0.121s
ereg 0m0.123s — 0m0.123s
Видим не такой уж большой разрыв.
Снова строка 64 байт. Искомое присутствет в начале строки:
preg 0m0.131s — 0m0.140s
ereg 0m0.179s — 0m0.183s
Снова строка 64 байт. Искомое присутствет в конце строки:
preg 0m0.203s — 0m0.218s
ereg 0m0.494s — 0m0.503s
Регексп с патерном в 11 символов (в центре) по строке в 64 символа
preg 0m0.143s — 0m0.146s
ereg 0m0.647s — 0m0.664s
>echo $var."text" быстрее, чем echo "$var text"
Одинаково. А то и медленнее. Быстрее будет
echo $var.'text'
Ещё быстрее echo $var,'text'
А ещё быстрее echo $var ?>text<?php
А ещё быстрее echo $var ?>text<?php
shitcode detected… :)
Вот благодаря таким советам потом и появляются матюки…
Такой код поддерживать — это чистый вынос мозга.
Вот благодаря таким советам потом и появляются матюки…
Такой код поддерживать — это чистый вынос мозга.
Во-первых я не говорил, что этот код лучше. Он быстрее, согласны?
Во-вторых такой код вполне приемлем в шаблоне. И он очень красиво смотрится.
Во-вторых такой код вполне приемлем в шаблоне. И он очень красиво смотрится.
<?php if($f->type == 'visible'): ?>
<tr>
<td class="label"><?php echo $f->label; ?>:</td>
<td><?php echo $f->element; ?></td>
</tr>
<?php elseif($f->type == 'hidden'): ?>
<tr style="display: none;">
<td colspan="2"><?php echo $f->element; ?></td>
</tr>
<?php endif; ?>честно говоря, за такую мешанину кода и оформления я бы расстреливал на месте
Во-во, php вообще должен генерировать только xml, нечего всем этим td, tr делать в .php-файле.
Это кусок нормальной вьюхи. То есть полноценный шаблон.
Который не вгоняет в ступор верстальщика, который что-то стоит.
Мешанина html и php выглядит далеко не так.
Который не вгоняет в ступор верстальщика, который что-то стоит.
Мешанина html и php выглядит далеко не так.
В ступор может и не вгоняет — но к чему верстальщику php-логика с лишними для него тегами в шаблоне? Визуальный мусор, который можно править только в текстовом редакторе. А часто приходится гнать наблоны из готовой верстки чуть ли не прямо из DW. В идеале он должен выдать чистый html с названиями переменных на нужных местах. Не касаясь холиваров по поводу шаблонизаторов — с точки зрения верстальщика такой удобный способ был реализован в пресловутом и далеко не идеальном vBulletin (особенно в старых версиях до 3.x)
В шаблонах не должно быть бизнес-логики. С этим я разумеется согласен.
Далее.
Все шаблонизаторы, это забавная идея: а давайте мы предположим, что верстальщик дебил и сделаем недоязык для его недомозга. Этого ему хватит в 96% случаев.
Я был сторонником этой идеи. К счастью это в очень далёком прошлом.
Если вы в шаблонах хотите ограничиться только переменными, то файлов шаблонов будет ну очень много в более менее серьезных вещах.
Далее.
Все шаблонизаторы, это забавная идея: а давайте мы предположим, что верстальщик дебил и сделаем недоязык для его недомозга. Этого ему хватит в 96% случаев.
Я был сторонником этой идеи. К счастью это в очень далёком прошлом.
Если вы в шаблонах хотите ограничиться только переменными, то файлов шаблонов будет ну очень много в более менее серьезных вещах.
Их количество это наверное единственный минус такого подхода.
Вот если все такие умные, то почему среди лучших free CMS, по различным версиям, являются такие костыли, как Joomla, Wordpress или Drupal?
Про платные я вообще молчу. Одному Ктулху известно, что кроется в их загварженом коде.
Так где же она тогда, эта идеальная CMS?
К слову, все вышеперечисленные free используют нативный шаблонизатор. Однако ползать, как беременным тараканам, этим CMS ничто не мешает.
Про платные я вообще молчу. Одному Ктулху известно, что кроется в их загварженом коде.
Так где же она тогда, эта идеальная CMS?
К слову, все вышеперечисленные free используют нативный шаблонизатор. Однако ползать, как беременным тараканам, этим CMS ничто не мешает.
без шортегов не кошеро
Лично я от такого кода ушел давным-давно, когда понял, что стоимость установки второго-третьего-четвертого сервера, чем городить такие вот заглушки в HTML-е… мне намного больше нравится вот такой код:
1 файл somefile.php:
<
…
$this->smarty->assign(«somedata», $f->data);
…
?>
2 файл somefile.tpl:
{-- if $item.type eq 'visible' --}
{-- $item.label --}
{-- $item.element --}
{-- elseif $item.type eq 'hidden' --}
{-- $item.element --}
{-- /if --}
Хотя если быть точным, то подобный кусок кода примера — вообще является полным гавном… так как в такой структуре данных явно есть какая-то ошибка.
1 файл somefile.php:
<
…
$this->smarty->assign(«somedata», $f->data);
…
?>
2 файл somefile.tpl:
{-- if $item.type eq 'visible' --}
{-- $item.label --}
{-- $item.element --}
{-- elseif $item.type eq 'hidden' --}
{-- $item.element --}
{-- /if --}
Хотя если быть точным, то подобный кусок кода примера — вообще является полным гавном… так как в такой структуре данных явно есть какая-то ошибка.
парсер лох… вырезал нафик все теги, блин… (
{-- if $item.type eq 'visible' --}
<tr>
<td class=«label»>{-- $item.label --}</td>
<td>{-- $item.element --}</td>
</tr>
{-- elseif $item.type eq 'hidden' --}
<tr style=«display: none;»>
<td colspan=«2»>{-- $item.element --}</td>
</tr>
{-- /if --}
{-- if $item.type eq 'visible' --}
<tr>
<td class=«label»>{-- $item.label --}</td>
<td>{-- $item.element --}</td>
</tr>
{-- elseif $item.type eq 'hidden' --}
<tr style=«display: none;»>
<td colspan=«2»>{-- $item.element --}</td>
</tr>
{-- /if --}
К давнему аргументу холивара «пхп вс смарти» о том, что 96% (да-да, я измерял :) ) кода смарти «транслируется» в код пхп через find&replace возвращаться не буду :) Но вот в примере кода ничего предосудительного не вижу. Не поделитесь, что вы увидели?
Чтобы не переводить в тему холивара. Такого плана код применим в одном случае: на продакшне, с уже готовым дизайном и версткой, которому не требуются изменения, обкатанный на все 100% и приносящий достаточный доход. Если же у Вас проект в разработке, у которого не сильно большая нагрузка, идет добавление кучи функционала, части сайта могут меняться часто, и причем не только в HTML, но и при смене внутренней логики. Только представьте себе что будет, если потребуется изменить таблицу на див-блоки, а еще веселее если переименуется класс $f в нормальное и понятное для человека имя типа $users_list_data. Кстати имена переменных это совсем отдельный вопрос. Говорить о комментировании подобного кода это вообще полная прострация.
Извините, за сумбурность, несколько спешу, так как киндер которому 1 месяц очень сильно отвлекает от Хабра… ))
Извините, за сумбурность, несколько спешу, так как киндер которому 1 месяц очень сильно отвлекает от Хабра… ))
Вставлю и я своих пять копеек. Например если вы заранее знаете дату, то не стоит писать NOW() в запросе, можно вычислить время на стороне php и сразу подставить в запрос. То же самое в случае field1 -2 > 0, можно просто написать field1 > 2. Примеры синетические, но я думаю мысль в общем понятна.
Причина — MySQL (про другие сервера не знаю) не будет кэшировать результаты запроса с NOW(), а с чем-то вроде '2011-01-26 10:45:17' закэширует — если кэширование не используется, то и выигрыша не будет (вероятно). Плюс нужно быть осторожным с полями, автоматически изменяемыми при добавлении/изменение записи (типа created_at, updated_at) — время на аппсервере и сервере БД может различаться, пускай на миллисекунды, но нужные строки могут в результат не попасть (или попасть не нужные)
Для проектов где важна синхронизация всех клиентов (типа MMOG), лучше использовать во всех запросах $_SERVER['REQUEST_TIME'] не сколько с целью оптимизации (кэширование всё равно работать не будет, если в запрос включен id клиента и запросы реже раза в секунду) сколько с целью точной синхронизации.
Для проектов где важна синхронизация всех клиентов (типа MMOG), лучше использовать во всех запросах $_SERVER['REQUEST_TIME'] не сколько с целью оптимизации (кэширование всё равно работать не будет, если в запрос включен id клиента и запросы реже раза в секунду) сколько с целью точной синхронизации.
Кэширование — это только один аспект NOW(), это влияет за собой репликацию как минимум. Что касается системных часов, то я всегда считал что они должны синхронизироваться с эталоном (будет эталоном общедоступный сервер времени или локально поднятый, здесь уже не так важно).
P.S. Я редко сталкивался с проектами, в которых рассинхронизация времени на милисекунды была бы критична.
P.S. Я редко сталкивался с проектами, в которых рассинхронизация времени на милисекунды была бы критична.
Старайтесь не использовать require_once или include_once неоднократно по отношению к одному и тому же файлу. Иначе Вы элементарно теряете время на повторное считывание файла.
Возможно автор имел ввиду require или include? Потому как при использовании require_once интерпретатор проверяет, был ли подключен указанный файл ранее или нет, и если да повторного подключения не будет.
* Постоянно профилируйте свой код на сервере (xdebug) и на клиенте (firebug), что бы выявить узкие места кода
и так, на production, отжирая 50% проца, висел xdebug…
* «Критически тяжёлые» функции желательно реализовать на стороннем языка программирования в виде расширения PHP
ага. а как часто это будет отваливаться — никто не учитывает?
* Различие повремени на клиенте может составлять около 1 секунды, поэтому имеет смысл четкое разделение статики и генерируемых средствами PHP страниц.
это как? или у нас PHP на клиентской стороне обрабатывается?
* Старайтесь не использовать require_once или include_once неоднократно по отношению к одному и тому же файлу Иначе Вы элементарно теряете время на повторное считывание файла.
буга. бугага. бугагагагага. на то они и once, чтобы повторно не считывать. или вы еще на 4.2 где этот баг был?
* Желательно использовать проверку отправляемых данных на клиенте Это вызвано тем, что при проверке данных на стороне клиента, резко снижается количество запросов с неверными данными. Системы проверки данных на клиенте строятся в основном с использованием JS и жестких элементов формы (select).
ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
* Желательно большие конструкций DOM для массивов данных строить на клиентеЭто очень эффективный метод оптимизации при работе с отображением большого объёма данных. Суть его сводится к следующему: на сервере подготавливается массив данных и передаётся клиенту, а построение конструкций DOM предоставляется JS функциям. В результате нагрузка частично перераспределяется с сервера на клиент.
это в gwt справедливою в PHP — нет.
* Используйте постоянное соединение с БД при малом количестве одновременно активных клиентов
первый небредовый совет )
* Например можно использовать следующий простой подход: получаем данные выборки из БД и сохраняем их как сериализованный массив в файл
так вот откуда растут монстры с миллионами (я видел) файлов кеша :)
и потом спрашивают — а что все тормозит.
запомните — никакие нахрен файлы не смогут управлять кешем так как тот же memcached.
* Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
ассемблер в студию
* По времени считывания пустого файла колебания от 0.001 для readfile до 0.002 для include.
это на калькуляторе или первом пентиуме?
у меня на сервере около 0.00013 для 1000 чтений.
* $row['id'] быстрее, чем $row[id]
это вообще ошибка в коде, доррогой мой. второй случай — исключение и приведение неизвестной константы к строке
Товагищи! У нас таки-завелся либо очень олскульный, либо просто говнокодер, который в века баз на миллионы строк, невроткубических можностей амазона оптимизирует PHP в стиле 4.2 кода бородатого 2000 года. Это ужасно и печально.
А вообще — десткая статья. Если надо выбирать между опддерживаемостью и оптимальностью — надо выбирать поддерживаемость, уж поверьте мне.
и так, на production, отжирая 50% проца, висел xdebug…
* «Критически тяжёлые» функции желательно реализовать на стороннем языка программирования в виде расширения PHP
ага. а как часто это будет отваливаться — никто не учитывает?
* Различие повремени на клиенте может составлять около 1 секунды, поэтому имеет смысл четкое разделение статики и генерируемых средствами PHP страниц.
это как? или у нас PHP на клиентской стороне обрабатывается?
* Старайтесь не использовать require_once или include_once неоднократно по отношению к одному и тому же файлу Иначе Вы элементарно теряете время на повторное считывание файла.
буга. бугага. бугагагагага. на то они и once, чтобы повторно не считывать. или вы еще на 4.2 где этот баг был?
* Желательно использовать проверку отправляемых данных на клиенте Это вызвано тем, что при проверке данных на стороне клиента, резко снижается количество запросов с неверными данными. Системы проверки данных на клиенте строятся в основном с использованием JS и жестких элементов формы (select).
ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
* Желательно большие конструкций DOM для массивов данных строить на клиентеЭто очень эффективный метод оптимизации при работе с отображением большого объёма данных. Суть его сводится к следующему: на сервере подготавливается массив данных и передаётся клиенту, а построение конструкций DOM предоставляется JS функциям. В результате нагрузка частично перераспределяется с сервера на клиент.
это в gwt справедливою в PHP — нет.
* Используйте постоянное соединение с БД при малом количестве одновременно активных клиентов
первый небредовый совет )
* Например можно использовать следующий простой подход: получаем данные выборки из БД и сохраняем их как сериализованный массив в файл
так вот откуда растут монстры с миллионами (я видел) файлов кеша :)
и потом спрашивают — а что все тормозит.
запомните — никакие нахрен файлы не смогут управлять кешем так как тот же memcached.
* Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
ассемблер в студию
* По времени считывания пустого файла колебания от 0.001 для readfile до 0.002 для include.
это на калькуляторе или первом пентиуме?
у меня на сервере около 0.00013 для 1000 чтений.
* $row['id'] быстрее, чем $row[id]
это вообще ошибка в коде, доррогой мой. второй случай — исключение и приведение неизвестной константы к строке
Товагищи! У нас таки-завелся либо очень олскульный, либо просто говнокодер, который в века баз на миллионы строк, невроткубических можностей амазона оптимизирует PHP в стиле 4.2 кода бородатого 2000 года. Это ужасно и печально.
А вообще — десткая статья. Если надо выбирать между опддерживаемостью и оптимальностью — надо выбирать поддерживаемость, уж поверьте мне.
>и так, на production, отжирая 50% проца, висел xdebug…
Ну как бы подразумевается, что речь идет о dev (на худой конец staging) окружении.
>ага. а как часто это будет отваливаться — никто не учитывает?
Кривизна рук в общем не учитывается, да.
>это как? или у нас PHP на клиентской стороне обрабатывается?
Отдаем статику ngnix, динамику — апачем+PHP. ЧЯДНТ?
>ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
Согласен, тут автор пишет о том чего не знает (не понимает).
>это в gwt справедливою в PHP — нет.
От сервера получаем массив вида row=>[cell1, cell2, cell3]… и строим таблицу JS'ом. Что не так?
…
Далее согласен. Экономия на спичках возведенная в фетиш порождает чудовищ.
Ну как бы подразумевается, что речь идет о dev (на худой конец staging) окружении.
>ага. а как часто это будет отваливаться — никто не учитывает?
Кривизна рук в общем не учитывается, да.
>это как? или у нас PHP на клиентской стороне обрабатывается?
Отдаем статику ngnix, динамику — апачем+PHP. ЧЯДНТ?
>ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
Согласен, тут автор пишет о том чего не знает (не понимает).
>это в gwt справедливою в PHP — нет.
От сервера получаем массив вида row=>[cell1, cell2, cell3]… и строим таблицу JS'ом. Что не так?
…
Далее согласен. Экономия на спичках возведенная в фетиш порождает чудовищ.
>>ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
>Согласен, тут автор пишет о том чего не знает (не понимает).
Насколько я понимаю, никто не предлагает отменять серверную проверку.
Клиентская проверка должна отсекать ошибки в синтаксисе, либо заполненности обязательных полей. Таким образом кол-во запросов на сервер снизится.
>Согласен, тут автор пишет о том чего не знает (не понимает).
Насколько я понимаю, никто не предлагает отменять серверную проверку.
Клиентская проверка должна отсекать ошибки в синтаксисе, либо заполненности обязательных полей. Таким образом кол-во запросов на сервер снизится.
require быстрее, чем include для интерпретируемых файловага, в php4
Замечание: при ветвлении алгоритма, когда есть возможность не использовать интерпретируемый файл, надо использовать include, т.к. require подключает файл всегда.
>Использование «отработавших» переменных быстрее, чем объявление новых
>Или перефразирую иначе – Не создавайте лишних переменных.
Фаулер в своём «Рефакторинге» считает ровно наоборот: одна переменная — одно назначение, в идеале одно присваивание
>Или перефразирую иначе – Не создавайте лишних переменных.
Фаулер в своём «Рефакторинге» считает ровно наоборот: одна переменная — одно назначение, в идеале одно присваивание
Рефакторинг — это не оптимизация, а улучшение поддерживаемости и читабельности.
То, что описано в статье — это не оптимизация, а фигня полнейшая.
Оптимизация — по-моему, это, например, Substitute Algorithm у того же Фаулера.
Использование же «отработавших» переменных — это идиотизм, а не оптимизация (не в обиду будет сказано) :) Нужно не экономить на спичках, а решать реальные проблемы производительности с профайлером наголо — есть ведь замечательные инструменты вроде webgrind.
И оптимизировать отрефакторенный код не в пример легче и проще, чем код, который необдуманно следует всем вышеприведенным советам.
В общем, «предварительная оптимизация — корень всего зла» © :)
Использование же «отработавших» переменных — это идиотизм, а не оптимизация (не в обиду будет сказано) :) Нужно не экономить на спичках, а решать реальные проблемы производительности с профайлером наголо — есть ведь замечательные инструменты вроде webgrind.
И оптимизировать отрефакторенный код не в пример легче и проще, чем код, который необдуманно следует всем вышеприведенным советам.
В общем, «предварительная оптимизация — корень всего зла» © :)
Рефакторинг — это оптимизация поддерживаемости и читабельности. Вообще хотел сказать, что если одна часть советов не улучшает поддерживаемости и читабельности при хоть каком-то выигрыше, то другая их сильно ухудшает. Если автор писал для новичков, до я бы на его месте эти части отделил бы друг от друга или иным способом пометил «безболезненные» и «болезненные» оптимизации
Статья для общего развития.
>preg _replace быстрее, чем ereg_replace, str_replace быстрее, чем preg_replace, но strtr быстрее, чем str_replace
Разница во времени зависит от объёма данных и может достигать нескольких тысячных секунд.
Функции работы со строками быстрее, чем регулярные выражения
Это правило является следствием предыдущего.
А мы случайно причину со следствием не путаем?
Разница во времени зависит от объёма данных и может достигать нескольких тысячных секунд.
Функции работы со строками быстрее, чем регулярные выражения
Это правило является следствием предыдущего.
А мы случайно причину со следствием не путаем?
Друзья, а кто-нибудь может внятно объяснить, почему "$row['id'] быстрее, чем $row[id]", да ещё и аж в 7 раз?
Заранее спасибо!
Заранее спасибо!
Во втором случае интерпретатор сначала ищет константу с именем id, не находит (если повезло :) ), создаёт её, инициализирует строкой 'id', разыменовывает и только после этого подставляет полученную строку. Попутно выдает предупреждение, вообще конструкция $row[id] считается грубой ошибкой
Спасибо! Теперь в голове сложилась картинка.
а использование «текст $row[id] текст» — тоже плохо?
а использование «текст $row[id] текст» — тоже плохо?
Плохо, очень плохо. Даже для читабельности кода.
Да и кавычки двойные тут на 0.000000001 секунды замедлят сразу же скрипт :)
Да и кавычки двойные тут на 0.000000001 секунды замедлят сразу же скрипт :)
выходит
echo «текст ». $row['id']. " текст"
лучше чем
echo «текст $row[id] текст»
так?
echo «текст ». $row['id']. " текст"
лучше чем
echo «текст $row[id] текст»
так?
нет. «text $var text» быстрее чем «text ».$var." text". Конкатенация работает медленнее, чем поиск переменных внутри строки.
P.S. А «текст $row[id] текст» разве работает? Наверное все-таки «текст {$row['id']} текст», не?
P.S. А «текст $row[id] текст» разве работает? Наверное все-таки «текст {$row['id']} текст», не?
«текст $row[id] текст» — точно работает. часто пользовался, потому и интересуюсь.
«текст {$row['id']} текст» — про такое не знал :\
«текст {$row['id']} текст» — про такое не знал :\
P.S. А «текст $row[id] текст» разве работает? Наверное все-таки «текст {$row['id']} текст», не?
Работает и совершенно корректная конструкция.
Если прдварительно определить константу id и в row будет такой ключ ;)
наоборот. конкатенация быстрее. почитайте те же symfony coding standarts.
и да, «текст $row[id] текст» работает.
и да, «текст $row[id] текст» работает.
echo «текст ». $row['id']. " текст"
лучше чем
echo «текст $row[id] текст»
Нет. В большинстве случаев переменные прям строке намного лучше, чем конкатенация через точку.
а еще лучше помогать интерпретатору выделяя переменные фигурными скобками:
echo "текст {$row['id']} текст";echo "текст {$row['id']} текст";
// vs
echo "текст $row[id] текст";
;)
Только что проверил, разницы вообще нет.
На Core i5-750 и PHP 5.3.3, результаты одинаковы: ~0.8с для миллиона(!) выводов, причем это не чистое время, т.к. есть оверхед из-за фора.
<?
$row = array('id' => 1297);
$results = array();
$tests = 1000000;
$start = microtime(true);
for($i = $tests; $i-- > 0;)
echo $row['id'] , ' title';
$results[] = (- $start + ($start = microtime(true)));
for($i = $tests; $i-- > 0;)
echo $row['id'] . ' title';
$results[] = (- $start + ($start = microtime(true)));
for($i = $tests; $i-- > 0;)
echo "$row[id] title";
$results[] = (- $start + ($start = microtime(true)));
for($i = $tests; $i-- > 0;)
echo "{$row['id']} title";
$results[] = (- $start + ($start = microtime(true)));
var_dump($results);
?>На Core i5-750 и PHP 5.3.3, результаты одинаковы: ~0.8с для миллиона(!) выводов, причем это не чистое время, т.к. есть оверхед из-за фора.
Конечно нету =) Разница только визуальная
А откуда ж браться разнице? Парсер, он же не дурак. Он один раз всё парсит, а потом просто выполняет :)
А с точки зрения выполнения конструкции почти одинаковые.
А с точки зрения выполнения конструкции почти одинаковые.
Почему-то мне кажется, что $row[id] должна выдавать варниг в любом контексте (если все ошибки включены)
shock@shock:~$ php -r 'error_reporting(E_ALL | E_STRICT | E_NOTICE);
$array = array("id" => 15);
echo "$array[id]\n";'
15
shock@shock:~$ php -v
PHP 5.3.1-0.dotdeb.1
Спасибо, интересно, не знал :) Но пользоваться, пожалуй, не буду
На дотдебе, кстати, 5.3.5 уже давненько (относительно) лежит, или есть причины 5.3.1 использовать?
На дотдебе, кстати, 5.3.5 уже давненько (относительно) лежит, или есть причины 5.3.1 использовать?
Я просто сейчас на компе, который давно не апгрейдил. Даже ось старая стоит. Всё хочу поставить другой дистр, но никак не найду времени.
Вывод — причин нету.
Вывод — причин нету.
Пожалуйста. Кстати, почитать можно тут: php.net/manual/en/language.types.array.php
Начиная со слов «More examples to demonstrate this behaviour: „
Начиная со слов «More examples to demonstrate this behaviour: „
это понятно. но настолько ли отсутствие конкатенации лучше, что компенсирует в 7 раз большую «медленность» конструкции $row[id] по сравнению с $row['id']?
Ужас.
Тупые советы, значительно ухудшающие код (используйте одни и те же переменные, не используйте ООП, не вызывайте функции), основанные на догадках (1/2 вызывает деление? Не верю что интерпретатор PHP настолько туп), действующие далеко не всегда (ajax значительно быстрее? Под большой нагрузкой, вовсе не факт, что 10 маленьких запросов отработают быстрее, чем один большой), экономящие аж тысячные/милионные доли секунды.
При том что грамотные индексы, кэширование, акселераторы, правильные алгоритмы дадут прирост производительности выше на несколько порядков.
Тупые советы, значительно ухудшающие код (используйте одни и те же переменные, не используйте ООП, не вызывайте функции), основанные на догадках (1/2 вызывает деление? Не верю что интерпретатор PHP настолько туп), действующие далеко не всегда (ajax значительно быстрее? Под большой нагрузкой, вовсе не факт, что 10 маленьких запросов отработают быстрее, чем один большой), экономящие аж тысячные/милионные доли секунды.
При том что грамотные индексы, кэширование, акселераторы, правильные алгоритмы дадут прирост производительности выше на несколько порядков.
Как говорил то ли Фаулер, то ли Бек: «Окончательный ответ может дать только профайлер». Это раз.
Ну и во-вторых, на продакшне можно ставить xhprof, хотя бы на одном из серверов, если на то есть необходимость.
Но, как показывает опыт, узкое место всегда одно и то же: база данных,
Ну и во-вторых, на продакшне можно ставить xhprof, хотя бы на одном из серверов, если на то есть необходимость.
Но, как показывает опыт, узкое место всегда одно и то же: база данных,
0.5 быстрее, чем 1/2 Причина в том, что во втором случае выполняется операция деления.Кэп? Конечно во втором случае делится, а в первом константа.
Теперь без шуток. 200/2 быстрее чем 200 * 0.5 ибо в первом случае выполняется целочисленное деление, а во втором случае умножение в FPU вот 1.5/2 будет медленнее в 2 раза чем 1.5*0.5 тест когда-то проводился на Intel Pentium IV Так что тут нельзя однозначно заявлять.
ob_start(); echo 'a'; echo 'b'; ob_end_flush(); быстрее, чем $return='a'; $return.='b'; echo $return;
смеетесь? то есть установить глобальный перехват вывода PHP БЫСТРЕЕ, чем напечатать переменную?!
смеетесь? то есть установить глобальный перехват вывода PHP БЫСТРЕЕ, чем напечатать переменную?!
echo $var."text" быстрее, чем echo "$var text"Скажите мне, а где тут разница?
PHP все равно зайдет в двойные кавычки для поиска переменной.
Правильней будет так:
echo $var . 'text' быстрее, чем echo "$var text"
Ужас какой то. Особенно про «Использование сложных запросов к БД быстрее».
Ага. Вот есть в проекте у нас такие запросы, по 10 джоинов, в таблицах чуть ли не по миллиону записей. Запрос аж 6 секунда выполняется иногда ) И вот попробуй докажи, всё пытаются какие-то неведомые индексы к таблицам добавить )))
У нас в проекте несколько таблиц милионников размерами от сотен до гигабайт, запросы больше 0.2с редкость, да и те в моменты пиковой нагрузки. Индексы решают, главное правильно ими пользоваться, только расстановки индексов не всегда достаточно, частенько надо немного поправить сам запрос, а иногда и переписать.
да тут к половине советов надо приписывать «в некоторых случаях ...»
сломал глаза, смотря на это:
плюсующих статью больше чем минусующих. мда, хабр уже не торт.
вот повисит такое на главной, детишки поначитаются, и на полном серьёзе будут делать «профессиональные вставки» и пр.
вот повисит такое на главной, детишки поначитаются, и на полном серьёзе будут делать «профессиональные вставки» и пр.
«Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i»
Начинать работать с не инициализированными переменными нельзя, или у вас поощряются нотисы?
Да и вообще, 80% советов можно смело переносить в пункт «Бесполезная оптимизация».
Если же у вас проект, в котором нагрузки такие, что не хватает скорости самого php, то думаю что нужно менять язык, а не применять эти советы.
Начинать работать с не инициализированными переменными нельзя, или у вас поощряются нотисы?
Да и вообще, 80% советов можно смело переносить в пункт «Бесполезная оптимизация».
Если же у вас проект, в котором нагрузки такие, что не хватает скорости самого php, то думаю что нужно менять язык, а не применять эти советы.
В этом году еще не было.
«Использование сложных запросов к БД быстрее, чем использование нескольких простых»
Очень спорный момент, не стоит перекладывать нагрузку на сервер БД, когда база начнет задыхаться её будет сложнее масштабировать.
Очень спорный момент, не стоит перекладывать нагрузку на сервер БД, когда база начнет задыхаться её будет сложнее масштабировать.
> Получение данных из файла быстрее, чем из БД
Есть много случаев когда обращение к БД быстрее:
— запрос попал в кеш, выборка делается из ОЗУ, что априори на порядки быстрее чем чтение из файла.
— запрос в таблицу типа MEMORY, тут собственно опять нету обращения к диску, поэтому как и в предыдущем вариант на порядки быстрее.
— запрос «в индекс» будет быстрее в большинстве случаях, ибо индекс обычно «висит» в памяти, что в очередной раз быстрее на порядки чем обращение к диску
— …
Подобных оптимизаций со стороны БД достаточно много, чтобы все тут перечислять, стоит ли овчинка выделки?
> Если данные выборки из БД редко меняются и к этим данным обращается множество пользователей, то имеет смысл сохранить данные выборки в файл
И тут не согласен:
— если данные редко меняются и часто читаются — БД сама всё закеширует (для несложных запросов естественно)
— если данные и редко читаются, и редко меняются, то стоит лих их вообще куда-то кешировать?
— если запрос сложный и часто испольщуется, то:
1) можно кешировать данные в PHP, например с помощью APC или memcached
2) закешировать в таблицу типа MEMORY. Например, для материализованных вьюх.
Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
вы разрабатываете PHP4? В PHP 5.3 разница не такая существенная, а вот проект поддерживать несоизмеримо проще.
Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i
Это не должно быть оптимизацией, т. к. переменные надо инициализировать всегда.
Использование «отработавших» переменных быстрее, чем объявление новых
Попробуйте отладить код состоящий из переменных $a, $b, $i, $tmp, $temp,… Данное утверждение верно только в том случае, когда новое значение будет такого же типа как старое ;-)
Есть много случаев когда обращение к БД быстрее:
— запрос попал в кеш, выборка делается из ОЗУ, что априори на порядки быстрее чем чтение из файла.
— запрос в таблицу типа MEMORY, тут собственно опять нету обращения к диску, поэтому как и в предыдущем вариант на порядки быстрее.
— запрос «в индекс» будет быстрее в большинстве случаях, ибо индекс обычно «висит» в памяти, что в очередной раз быстрее на порядки чем обращение к диску
— …
Подобных оптимизаций со стороны БД достаточно много, чтобы все тут перечислять, стоит ли овчинка выделки?
> Если данные выборки из БД редко меняются и к этим данным обращается множество пользователей, то имеет смысл сохранить данные выборки в файл
И тут не согласен:
— если данные редко меняются и часто читаются — БД сама всё закеширует (для несложных запросов естественно)
— если данные и редко читаются, и редко меняются, то стоит лих их вообще куда-то кешировать?
— если запрос сложный и часто испольщуется, то:
1) можно кешировать данные в PHP, например с помощью APC или memcached
2) закешировать в таблицу типа MEMORY. Например, для материализованных вьюх.
Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
вы разрабатываете PHP4? В PHP 5.3 разница не такая существенная, а вот проект поддерживать несоизмеримо проще.
Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i
Это не должно быть оптимизацией, т. к. переменные надо инициализировать всегда.
Использование «отработавших» переменных быстрее, чем объявление новых
Попробуйте отладить код состоящий из переменных $a, $b, $i, $tmp, $temp,… Данное утверждение верно только в том случае, когда новое значение будет такого же типа как старое ;-)
Если уж так, то где про хранение «NULL» в базе?
Когда-то столкнулся с вариантом, что:
$array['a'] = 1;
$array['b'] = 1;
$array['c'] = 1;
И потом if (isset($array['a'])) {} На порядок быстрее, чем создание массива $array = array('a', 'b', 'c'); и последующий поиск переменной в нем.
$array['a'] = 1;
$array['b'] = 1;
$array['c'] = 1;
И потом if (isset($array['a'])) {} На порядок быстрее, чем создание массива $array = array('a', 'b', 'c'); и последующий поиск переменной в нем.
искали чем?
in_array
array_search
array_search
странно, вообще насколько мне известно, пхп хранит такие хэши в виде двух массивов — массив ключей и массив значений. то есть разницы быть не должно никакой — и в том, и в другом случае пхп сканирует массив, совершенно одинаковым способом.
www.google.com.ua/search?hl=ru&q=in_array+slow&aq=f&aqi=&aql=&oq=
В целом — можете проверить за пару минут — сгенерируйте два массива по 1000 элементов и потом пройдитесь по нему с таймером. Разница между isset и in_array будет очень ощутимая.
В целом — можете проверить за пару минут — сгенерируйте два массива по 1000 элементов и потом пройдитесь по нему с таймером. Разница между isset и in_array будет очень ощутимая.
Почти весь выигрыш от оптимизация PHP-кода сожрется 4-5 запросами (даже оптимизированными) к БД.
И вообще, советы детсадовские. Например, про инкремент несуществующей переменной. Я даже не знаю, кому бы это пришло в голову :-)
И вообще, советы детсадовские. Например, про инкремент несуществующей переменной. Я даже не знаю, кому бы это пришло в голову :-)
на большом количестве запросов в секунду (к бд конечно же) — пконнект выгоднее, ибо tcp коннект (а ведь там происходит много всего включая аутентификацию) может быть медленнее, чем простой запрос и быстрый ответ. попробуйте простые «прекомпиленные» запросы через mysqli (ну или Perl DBD) использовать — на большых rps особенно заметно
Вот почему у меня они не глючат то?
Никакой винды, БД уже лет 10 как на отдельных серверах, так что речи о unix sockets вообще не идет.
В принципе я говорил не совсем о high load в истинном понимании. Просто сталкивался с задачей по быстрому впихиванию в бд простых и мелких данных, генерящихся «на лету» типа логов. Выигрыш от использования «пконнекта» был заметен, а использование mysqli->prepare, bind_param, execute добавило еще скорости вставки в разы.
P.S. пойду сделаю тестик :-)
Никакой винды, БД уже лет 10 как на отдельных серверах, так что речи о unix sockets вообще не идет.
В принципе я говорил не совсем о high load в истинном понимании. Просто сталкивался с задачей по быстрому впихиванию в бд простых и мелких данных, генерящихся «на лету» типа логов. Выигрыш от использования «пконнекта» был заметен, а использование mysqli->prepare, bind_param, execute добавило еще скорости вставки в разы.
P.S. пойду сделаю тестик :-)
# echo быстрее, чем print
Спасибо, вы раскрыли причину тормозов Друпала! :-)
show full processlist сам по себе стоит в сто раз дороже чем все эти советы вместе взятые
Мне кажется, что совет «Не делайте запросы в цикле» полезнее всей этой статьи :)
Многие советы никакой пользы не несут, некоторые вредные. Похоже на советы для говно-кодеров…
Не написано даже банальное, что надо писать чистый код и без собак, потому что на генерацию и подавление ошибок тратиться время.
Не написано даже банальное, что надо писать чистый код и без собак, потому что на генерацию и подавление ошибок тратиться время.
x = sizeOf($array); for($i = 0; $i < x; ++$i) {...} быстрее, чем for($i = 0; $i < sizeOf($array); ++$i) {...}
Скажу по секрету, что по-человечески это записывается так:
for ($i = 0, $l = sizeOf($array); $i < $l; $i++) {...}
$_SERVER[’REQUEST_TIME’] быстрее, чем time() для определения времени запуска скрипта
Причина в том, что в первом случае нет использования функции.
А как ты причину выяснил? Наугад что ли? Настоящая причина этого в том, что если использовать $_SERVER[’REQUEST_TIME’], то обращение к системному таймеру ОС идет один раз, а в случае time() — при каждом вызове.
Серьезно?! И в какой момент оно идёт?
Перед исполнением PHP-скипта.
Так может корректнее написать «то обращение к системному таймеру ОС идет один раз, до выполнения PHP-скипта, а в случае time() — ещё и при каждом её вызове?
Но главное, почему я не люблю использовать time — даже первой строчкой в скрипте она может вернуть время уже отличное от $_SERVER[’REQUEST_TIME’]
Но главное, почему я не люблю использовать time — даже первой строчкой в скрипте она может вернуть время уже отличное от $_SERVER[’REQUEST_TIME’]
return быстрее, чем global при возвращении значения переменной из функции
Это вызвано тем, что во втором случае создаётся глобальная переменная.
Кто-то возвращает данные из функции через global? Серьезно?
Вы что серьёзно хотите повысить быстродействие современного веб-приложения советами типо "++i быстрее, чем i++"? Узкое место большинства веб-приложения — это запросы к бд, а использование кешеров (APC, xcache и т.д.) и перевод хотя бы части данных из СУБД в Redis или Memcache увеличит быстродействие в 100500 раз больше, по сравнению с тем, что Вы советуете.
Попробую сформулировать общие правила.
Операции получения данных в PHP, упорядоченные по скорости:
1. Чтение данных из памяти (поэтому можно кешировать данные даже в процессе выполнения одной страницы, другими словами никогда не читать из БД/файлов одно и то же дважды).
2. Чтение массива из файла (все статичные данные, по которым не надо вести сложный поиск, следует писать в php-файлы в виде массивов и подгружать их через include по необходимости).
3. Чтение из БД (СУБД сама оптимизирует — что в памяти, а что в файлах), если БД не перегружена. При большом количестве пользователей лучше несколько мелких запросов, чем один сложный (чтобы не создавать длинных очередей).
4. Чтение и интерпретация файлов (XML must die).
Это базовая оптимизация. Основные задержки идут при запросах к БД, так что оптимизировать надо в первую очередь их. И всегда использовать файловый (или в памяти) кеш (хотя бы и со временем жизни в 5 секунд), если отображение «живых» данных не критично.
Операции получения данных в PHP, упорядоченные по скорости:
1. Чтение данных из памяти (поэтому можно кешировать данные даже в процессе выполнения одной страницы, другими словами никогда не читать из БД/файлов одно и то же дважды).
2. Чтение массива из файла (все статичные данные, по которым не надо вести сложный поиск, следует писать в php-файлы в виде массивов и подгружать их через include по необходимости).
3. Чтение из БД (СУБД сама оптимизирует — что в памяти, а что в файлах), если БД не перегружена. При большом количестве пользователей лучше несколько мелких запросов, чем один сложный (чтобы не создавать длинных очередей).
4. Чтение и интерпретация файлов (XML must die).
Это базовая оптимизация. Основные задержки идут при запросах к БД, так что оптимизировать надо в первую очередь их. И всегда использовать файловый (или в памяти) кеш (хотя бы и со временем жизни в 5 секунд), если отображение «живых» данных не критично.
require быстрее, чем include для интерпретируемых файлов
ну, на сколько я понял из исходников, это одно и то же :)
Вы не понимаете сути оптимизации!!!!1 Надо попробовать вызвать каждую функцию стотысяч раз и замерить на мобильнике секундомером время, а потом — сравнить!
Это не одно и то же, они одинаково подключают файлы, но есть один маленький нюанс: include, если не найдет файл бросает варнинг, require же фатал. Это единственная разница.
Прочитав уже первый совет про профилирование файрбагом в статье по оптимизации PHP все должно стать ясно.
У меня дежавю…
Неужели кто-то еще не усвоил эти вещи?
Неужели кто-то еще не усвоил эти вещи?
Ну вот, коллективный разум работает. Статья получилась какбэ не очень, зато в комментах помимо флуда написали уже много годных вещей.
Статья бесполезна чуть более, чем полностью. Автор, не боитесь за свою профессиональную репутацию?
Перенесите в «Юмор»
Не комментированный код быстрее, чем комментированный, так как уходит дополнительное время на чтение файла
Весьма глупо уменьшать объём комментариев ради оптимизации, надо просто в рабочих («боевых») скриптах проводить минимизацию.
Вспомнил бородатый прикол с баша о том что если убрать слово fuck из комментариев в исходниках Линукса, то они будут весить на 200мб меньше :)
Отличный способ узнать что же реально влияет на скорость выполнения php — запостить статью про кавычки и ждать комментов.
Шо, опять?
Берём кешер опкода, используем кэш, а сэкономленное на спичечной оптимизации время тратим на забрасывание помидорами авторов таких статей.
>>readfile быстрее, чем file_get_contents, file_get_contents быстрее, чем require, а require быстрее, чем include
убило, первая функция сразу бросает содержимое в буфер, вторая в переменную, третья для подключения php кода с ОСТАНОВКОЙ выполнения в случае его отсутствия, четвёртая тоже что третья, но скрипт продолжает работать с E_WARNING.
>>readfile быстрее, чем file_get_contents, file_get_contents быстрее, чем require, а require быстрее, чем include
убило, первая функция сразу бросает содержимое в буфер, вторая в переменную, третья для подключения php кода с ОСТАНОВКОЙ выполнения в случае его отсутствия, четвёртая тоже что третья, но скрипт продолжает работать с E_WARNING.
>>Использование сложных запросов к БД быстрее, чем использование нескольких простых
Разница во времени зависит от многих факторов (объём данных, настройка БД и пр.) и измеряется тысячными, а иногда даже сотыми, секунды.
Про то, что это совершенно неверная информация — уже написали и правильно.
Добавлю, что в большенстве случаев разбивка сложного запроса на более простые способная увеличить скорость выполнения в десятки раз. Это связано чаще всего с оптимизатором СУБД. В сособенности, когда в разделе WHERE пишут целые полотна для «зато всего одним запросом!»
Разница во времени зависит от многих факторов (объём данных, настройка БД и пр.) и измеряется тысячными, а иногда даже сотыми, секунды.
Про то, что это совершенно неверная информация — уже написали и правильно.
Добавлю, что в большенстве случаев разбивка сложного запроса на более простые способная увеличить скорость выполнения в десятки раз. Это связано чаще всего с оптимизатором СУБД. В сособенности, когда в разделе WHERE пишут целые полотна для «зато всего одним запросом!»
Ну я думаю автор имел ввиду нечто такое:
Тогда да, безусловно один запрос будет быстрей чем эти два =)
$result = query('SELECT `user_id` FROM users;');
$result = query('SELECT * FROM `user_profile` WHERE `user_id` IN ( ' . $result . ' )');
Тогда да, безусловно один запрос будет быстрей чем эти два =)
>>$result = query('SELECT * FROM `user_profile` WHERE `user_id` IN ( '. $result. ' )');
Вот сколько уже раз людям говорят, что нельзя после SELECT ставить звездочки! Это ужасно! Уж лучше тогда перечислить все поля таблицы будет в 10 раз дешевле запрос. И, уверен, все поля в итоге не нужны. Это так, помимо прочего.
Вот сколько уже раз людям говорят, что нельзя после SELECT ставить звездочки! Это ужасно! Уж лучше тогда перечислить все поля таблицы будет в 10 раз дешевле запрос. И, уверен, все поля в итоге не нужны. Это так, помимо прочего.
А Вас вообще не смутила конструкция IN ( '. $result. ' )? Ниче что эта конструкция вообще не рабочая? Да и вообще какие могут быть поля к гипотетическим таблицам? Мне что придумать Вам на ходу схему бд чтоб пример написать? Это так, помимо прочего.
«Уж лучше тогда перечислить все поля таблицы будет в 10 раз дешевле запрос»
Кстати, вот с этим я поспорил бы =) Если на то пошло.
Кстати, вот с этим я поспорил бы =) Если на то пошло.
Ну вот, еще один… просто проверь
SELECT * FROM и SELECT field1, field2… field_last FROM будут равны по скорости, для мускула узнать поля в таблице занимает ничтожно мало времени, это никак не влияет на запрос. Другое дело если выбираются не все поля а лишь парочка, тогда да, будет быстрей.
еще раз — сначала проверь, иначе если я сам приведу примеры, вы будете выглядить не с лучшей стороны
CREATE TABLE `users` ( `user_id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_first_name` varchar(100) DEFAULT NULL, `user_last_name` varchar(100) DEFAULT NULL, `user_email` varchar(100) DEFAULT NULL, `user_phone` varchar(20) DEFAULT NULL, `user_birth_date` datetime DEFAULT NULL, `user_photo` varchar(255) DEFAULT NULL, `user_age` tinyint(4) DEFAULT NULL, PRIMARY KEY (`user_id`) ) ENGINE=MyISAM AUTO_INCREMENT=2289055 DEFAULT CHARSET=utf8 SELECT COUNT(*) FROM users - 2289054 SELECT * - 15,3 сек SELECT <перечислены все поля> - 16,1 сек
Данные вбиты случайно, строки длиной от 5 до 10 символов, фото от 10 до 50 символов.
заметы средние, делал по 5 раз. Винда семерка, настройки мускула дефолтные, машина рабочая, запущены всякие проги итд.
Еще раз: для мускула узнать колонки — плевое дело, это не значительно влияет на запрос, больше влияют кривые руки тех кто делает запросы.
Насчет
а что вообще движет людьми, которые до сих пор пишут второй вариант (с reset-while и т.п.)? Встречал таких несколько раз, и не так давно. Это ведь тупо больше кода (и больше языковых конструкций) при аналогичном результате. Привычка из бородатых времен или оплата за кол-во символов? :)
foreach ($arr as $key => $value) {...} быстрее, чем reset ($arr); while (list($key, $value) = each ($arr)) {...} для ассоциативных массивовс экономией 0.00.....1 секунды все понятно, вопрос в другом (немного не по теме):
а что вообще движет людьми, которые до сих пор пишут второй вариант (с reset-while и т.п.)? Встречал таких несколько раз, и не так давно. Это ведь тупо больше кода (и больше языковых конструкций) при аналогичном результате. Привычка из бородатых времен или оплата за кол-во символов? :)
Не вводите в заблуждение людей по поводу strtr и str_replace — это сильно разные функции.
Причем первая предназначена для «трансляции» символов, которые по доброте душевной расширили до «коротких слов».
На заменах слов внутри больших текстов strtr работает до 50 раз медленнее чем str_replace!
У меня шаблонизатор, уже 10 лет как на str_replace. Постоянно ищу более быструю замену, по мере выхода версий, но не нахожу ничего, кроме возможности написания отдельного модуля. Для подстановок, быстрее str_replace только sprintf, с предсказуемым порядком следования. Но это уже совсем из другой оперы.
Причем первая предназначена для «трансляции» символов, которые по доброте душевной расширили до «коротких слов».
На заменах слов внутри больших текстов strtr работает до 50 раз медленнее чем str_replace!
У меня шаблонизатор, уже 10 лет как на str_replace. Постоянно ищу более быструю замену, по мере выхода версий, но не нахожу ничего, кроме возможности написания отдельного модуля. Для подстановок, быстрее str_replace только sprintf, с предсказуемым порядком следования. Но это уже совсем из другой оперы.
" ++i быстрее, чем i++ " выражение ++i и i++ это не одно,
$a = 0;
$b = ++a;
echo $b; // 1
$a = 0;
$b = ++a;
echo $b; // 1
Статья — по сути тупо собранные воедино советы из кучи статей лохматых годов и времен PHP4.
Помню, при прочтении одной из таких статей ради интереса написал пару тестов и получил результаты, прямо противоречащие указанным советам.
Например, foreach() быстрее даже на массивах с идущими по порядку числовыми индексами, чем for (;;).
Впрочем, вышекомментящие уже верно отписали — смысла сидеть и оптимизировать php код такими оптимизациями (даже не outdated) — смысла не имеет, т.к. все скорее всего упрется в доступ к БД или в архитектуру всей системы.
Помню, при прочтении одной из таких статей ради интереса написал пару тестов и получил результаты, прямо противоречащие указанным советам.
Например, foreach() быстрее даже на массивах с идущими по порядку числовыми индексами, чем for (;;).
Впрочем, вышекомментящие уже верно отписали — смысла сидеть и оптимизировать php код такими оптимизациями (даже не outdated) — смысла не имеет, т.к. все скорее всего упрется в доступ к БД или в архитектуру всей системы.
print всё таки быстрее echo и этот факт стоит учитывать скажем в цикле выводя что-то.
А красиво сделанная разметка нужна в первую очередь не для скорости, а для того, чтобы можно было понять что вообще написано.
А то есть много уникумов (которые понаставят мне за это минусов), которые вместо того, чтобы думать о том, что этот код возможно будет кто-то править или смотреть, набивают по 4-5 пробелов где можно поставить табуляцию, или лепят всё в одну строчку, словно пишут шифровку в штаб, чтобы никто не догадался и потом приходится тратить долгое время, чтобы привести код в более-менее читабельный вид…
А красиво сделанная разметка нужна в первую очередь не для скорости, а для того, чтобы можно было понять что вообще написано.
А то есть много уникумов (которые понаставят мне за это минусов), которые вместо того, чтобы думать о том, что этот код возможно будет кто-то править или смотреть, набивают по 4-5 пробелов где можно поставить табуляцию, или лепят всё в одну строчку, словно пишут шифровку в штаб, чтобы никто не догадался и потом приходится тратить долгое время, чтобы привести код в более-менее читабельный вид…
Отлично. Некоторые данные, правда, устарели, но все же!
Опять же, быстрее писать сервер на ассемблере, чем на PHP, но жизни не хватит :).
За статью ГРАМАДНЕЙШЕЕ спасибо. Пишу пректик для себя, очень озабочен оптимизацией. Даже весь конфиг в массиве о_о.
За статью ГРАМАДНЕЙШЕЕ спасибо. Пишу пректик для себя, очень озабочен оптимизацией. Даже весь конфиг в массиве о_о.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сборник советов и фактов по оптимизации PHP-скриптов