Is one option generally faster than the other?
Option A: $var = $_GET['param'];
and then referencing $var
through the script.
Option B: Referencing $_GET['param']
in each occurrence through the script.
Thanks!

- 18,763
- 14
- 70
- 93
-
5Frankly, you will not be writing large enough scripts for it to matter either way. We're talking an extra couple of milliseconds, max, over the course of a non-trivial script. Pick whichever one is more understandable and maintainable. (Hint: Option A :P ) – cHao Mar 03 '13 at 00:12
-
1Basically you're asking how much overhead is a associated array key lookup. You should just run a quick test. Write a php script to use a key lookup to do something and run it a few hundred thousand times and time it, do the same with a direct variable instead and run it the same time and time it. Check the times and you'll see the overhead – R. S. Mar 03 '13 at 00:12
-
@cHao Are we talking about 2-3ms? Or is it less than that? – Mooseman Mar 03 '13 at 00:13
-
3@cHao: Milliseconds? I suspect even that's overstating it. – Mar 03 '13 at 00:14
-
@duskwuff: It probably is. I'm trying to be generous here. :) – cHao Mar 03 '13 at 00:14
-
3Anyway it is almost certain that you will validate your inptu. You might as well store it in a variable when you sanitize it. – Tchoupi Mar 03 '13 at 00:18
6 Answers
The difference in performance if any will be negligible and not worth the effort - so much so that even if you attempted to microtime it the difference would be consumed by random factors.
However Option A is better in terms of creating more sustainable code. e.g. If you ever wish to change the value of $var
you can do it from one position in your code.
Simply put this is never going to be the bottleneck in your program.

- 13,132
- 18
- 79
- 148
-
1+1 but "Also incrementing a global variable is 2 times slow...". Can we verify this? – Czar Pino Mar 03 '13 at 00:21
-
1@czarpino It is mentioned [here](http://stackoverflow.com/questions/2216340/the-advantage-disadvantage-between-global-variables-and-function-parameters-in#answer-2216350) and [here](http://www.mdproductions.ca/guides/50-best-practices-to-optimize-php-code-performance) and [here](http://my.opera.com/KenyLieou/blog/speed-up-your-php-code-site) however I just ran some tests on it and sometimes it was approximately twice as slow and others it was the same speed. So I will remove the statement as it isn't conclusive – George Reith Mar 03 '13 at 00:37
Benchmarked with 10000000
loops
$var = "bleh";
for ($i=0; $i<10000000; $i++) {
strlen($var);
}
and
$array = array();
$array['blah'] = "bleh";
for ($i=0; $i<10000000; $i++) {
strlen($array['blah']);
}
Results:
- Var: 8.563s - 856.3 nanoseconds per loop
- Array: 8.699s - 869.9 nanoseconds per loop
1.6% difference in speed.

- 1,505
- 13
- 19
-
Is this difference consistent? To get a valid benchmark you would need to run this test itself a large number of times, and average the performance of each approach. Also note that this isn't entirely the same as the question, which used a superglobal, which may well behave differently. – IMSoP Mar 03 '13 at 00:37
This kind of micro-optimisation is rarely worth thinking about. It's generally best to think about how best to architect your code, and leave such problems to the people writing the runtime of the language.
There are many factors that would be relevant if we really wanted to work out which was more efficient:
- how array access works to perform the
['param']
once or many times - how superglobals such as
$_GET
are implemented - how assignment is implemented (which in PHP uses "copy on write")
- how you pass
$var
around your code (e.g. as a function parameter) and how that is implemented - how often you need to read from the variable
- how often you write to the variable
I'm sure there are many more; and, of course, both your program and the PHP runtime its running in are subject to change on all of these points.

- 89,526
- 13
- 117
- 169
-
1Don't forget the lower level issues, like the compiler used to build PHP, cache locality, interrupts, currently running processes... :) That's a pretty deep rabbit hole... – cHao Mar 03 '13 at 00:33
Agreed with those that say you're worrying about the wrong level of optimization. (Though, if you really want to obsess over this sort of thing,check out http://www.phpbench.com/)
Your first level of optimization should be optimizing the readability and maintainability of the code. Human clock cycles are far more valuable and expensive (generally speaking) than computer clock cycles. As an added bonus, you'll be very pleasantly surprised how often optimizing for human clock cycles will also make the code remarkably faster.
I strongly recommend Clean Code by Robert C. Martin for an excellent guide to coding style.

- 620
- 3
- 17
A:
$var = $_GET['param']; // and then referencing $var through the script.
Requires a constant time, which is equal to zero in computer science.
B: Referencing
$_GET['param']; // in each occurrence through the script.
Is an ugly approach and is only done by "sloppy" programmers.
Let's say that you have to use $_GET['param']
10 times on a single page, or in multiple pages, and then you decide that you want to change 'param' to 'p' or 'parameter', then you're out of luck.
You want to initialize 'magic numbers' and 'magic values' to a variable (or a constant), which you can edit later on, and the programmer (whether It's your or someone else) doesn't have to know exactly what it is.
Imagine if programmers would use
if($number == 3.1415)
instead of
if($number == $pi)
it comes down to a similar basis.
So, NO, neither option is generally theoretically faster but option B is going to give you hell later on, and is ugly.

- 4,964
- 1
- 18
- 32
Use $_GET['param'] whenever you can. PHP has to remember $_GET['param']. By making a variable that is equal to $_GET['param'], PHP now has to remember two variables that are exactly the same.
Unless you're going to change the value of the new variable, it's faster to just use $_GET['param']. (Keep in mind, some people like to make new variables simply for readability)

- 324
- 1
- 7
-
2If your systems memory is small enough for this to be a problem then I think it is time for an upgrade. – George Reith Mar 03 '13 at 00:19
-
PHP uses "copy on write", so two variables that have the same value are just pointers to the same value. – IMSoP Mar 03 '13 at 00:23
-
@kormoc As I said below, this is nothing to do with string immutability, which I don't think is even true of PHP. – IMSoP Mar 03 '13 at 00:23
-
I wasn't saying this would be something that would severely slow down a script, but why make PHP do that extra work if you're not even going to alter the value? I think the answer varies depending on preference. – WackyWalrus Mar 03 '13 at 00:27
-
3@WackyWalrus "why make PHP do that extra work" - because that's its job! The entire point of a high-level programming language is to free us from thinking about what the machine is doing, and write code that helps us frame abstract problems. – IMSoP Mar 03 '13 at 00:31
-
@IMSoP I understand what you're saying, again, I think it's more of a preference. Most people prefer reading $var over $key['var']. I've just remembered people saying not to copy variables, [like this article from a google webmaster](https://developers.google.com/speed/articles/optimizing-php). – WackyWalrus Mar 03 '13 at 00:43
-
1
-
1@WackyWalrus: Your Google webmaster guy? He instantly lost credibility for using `mysql_query` non-ironically in 2012. Just saying. – cHao Mar 03 '13 at 03:27
-
Wow, apart from "no SQL in loops", that article is utter rubbish. Appears to date from when PHP 5.2 was current, but implies upgrading from PHP 3 is optional! And surely the memory in the last example is needed to pass from `strip_tags` to `echo` even with no variable? – IMSoP Mar 03 '13 at 11:52