2013-03-03 3 views
4

Есть один вариант, как правило, быстрее, чем другой?

Вариант A: $var = $_GET['param'];, а затем ссылка $var через сценарий.
Вариант B: Ссылка на $_GET['param'] в каждом случае через скрипт.

Спасибо!

+5

Честно говоря, вы не будете писать достаточно большие сценарии, чтобы это имело значение в любом случае. Мы говорим о дополнительной паре миллисекунд, максимум, в течение нетривиального сценария. Выберите, какой из них более понятным и поддерживаемым. (Подсказка: вариант A: P) – cHao

+1

В основном вы спрашиваете, сколько накладных расходов связано с поиском соответствующего массива. Вы должны просто выполнить быстрый тест. Напишите скрипт php, чтобы использовать ключевой поиск, чтобы что-то сделать, и запустить его несколько сотен тысяч раз и время, сделайте то же самое с прямой переменной и запустите его в одно и то же время и время. Проверьте время, и вы увидите накладные расходы – kormoc

+0

@cHao Мы говорим о 2-3 мс? Или это меньше? – Mooseman

ответ

7

Разница в производительности, если таковая имеется, будет незначительной и не стоит усилий - настолько, что даже если вы попытаетесь выполнить микропроцессор, разница будет потребляться случайными факторами.

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

Проще говоря это никогда не станет узким местом в вашей программе.

+1

+1, но «Также увеличивать глобальную переменную в 2 раза медленнее ...». Можем ли мы это проверить? –

+1

Спасибо за ответ! – Mooseman

+1

@czarpino Указано [здесь] (http://stackoverflow.com/questions/2216340/the-advantage-disadvantage-between-global-variables-and-function-parameters-in#answer-2216350) и [здесь] (http://www.mdproductions.ca/guides/50-best-practices-to-optimize-php-code-performance) и [здесь] (http://my.opera.com/KenyLieou/blog/speed- up-your-php-code-site), однако я просто провел несколько тестов, и иногда это было примерно в два раза медленнее, а другие - с той же скоростью. Поэтому я удалю оператор, поскольку он не является окончательным. –

-2

Используйте $ _GET ['param'], когда сможете. PHP должен помнить $ _GET ['param']. Сделав переменную, равную $ _GET ['param'], PHP теперь должен запомнить две переменные, которые являются точно такими же.

Если вы не собираетесь менять значение новой переменной, быстрее использовать $ _GET ['param']. (Имейте в виду, что некоторые люди хотели бы сделать новые переменные просто для удобства чтения)

+2

Если ваша системная память достаточно мала, чтобы это было проблемой, я думаю, что пришло время для обновления. –

+0

PHP использует «copy on write», поэтому две переменные, имеющие одно и то же значение, являются указателями на одно и то же значение. – IMSoP

+0

@kormoc Как я сказал ниже, это не имеет никакого отношения к неизменяемости строк, что, по моему мнению, даже не относится к PHP. – IMSoP

2

протестированные с 10000000 петель

$var = "bleh"; 
for ($i=0; $i<10000000; $i++) { 
strlen($var); 
} 

и

$array = array(); 
$array['blah'] = "bleh"; 
for ($i=0; $i<10000000; $i++) { 
strlen($array['blah']); 
} 

Результаты:

  • Var: 8,563 с - 856,3 наносекунды на петлю
  • Массив: 8,699 с - 869,9 наносекунд на петлю

1,6% разница в скорости.

+0

Является ли эта разница последовательной? Чтобы получить действительный контрольный показатель, вам нужно будет запустить этот тест сам по себе много раз и усреднить производительность каждого подхода. Также обратите внимание, что это не совсем то же самое, что вопрос, который использовал суперглобал, который может вести себя по-разному. – IMSoP

2

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

Есть много факторов, которые будут иметь значение, если мы действительно хотим, чтобы выработать который был более эффективным:

  • как доступ к массиву работает, чтобы выполнить ['param'] один или несколько раз
  • как Суперглобальные, такие как $_GET реализованы
  • Как выполняется реализация (в PHP используется «copy on write»)
  • как вы проходите $var вокруг вашего кода (например,в качестве параметра функции) и как что реализуется
  • как часто вам нужно прочитать из переменной
  • как часто вы пишете переменной

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

+1

Не забывайте о проблемах нижнего уровня, таких как компилятор, используемый для сборки PHP, локальность кэша, прерывания, текущие процессы ... :) Это довольно глубокая кроличья нора ... – cHao

0

A:

$var = $_GET['param']; // and then referencing $var through the script. 

Требует постоянное время, которое равно нулю в информатике.

B: Реферирование

$_GET['param']; // in each occurrence through the script. 

некрасивый подход и делается только "небрежный" программистов.

Предположим, что вы должны использовать $_GET['param'] 10 раз на одной странице или на нескольких страницах, а затем вы решите, что хотите изменить параметр «param» на «p» или «параметр», тогда вы отсутствуете удачи.

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

Представьте себе, если бы программисты используют

if($number == 3.1415) 

вместо

if($number == $pi) 

сводится к той же основе.

Итак, нет, ни один вариант, как правило, не теоретически быстрее, но вариант B даст вам ад позже и уродлив.

1

Согласен с теми, кто говорит, что вы беспокоитесь о неправильном уровне оптимизации. (Хотя, если вы действительно хотите зацикливаться на подобных вещах, ознакомьтесь с http://www.phpbench.com/)

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

Я настоятельно рекомендую Роберту К. Мартину Clean Code отличное руководство по стилю кодирования.