7

Summarized, I made a loop with a few iterations to check the efficiency of each test:

$iterations = 99999999;
$var = null;

isset comparasion

  if ( isset( $var ) )
  {

  }

'===' comparasion

  if ( $var === null )
  {

  }

And i have this log, in microseconds:

'isset()': 1.4792940616608
'===': 1.9428749084473

For me, this is a little curious. Why isset() function is faster than one comparison operator as ===?

Maximilian Ast
  • 2,954
  • 12
  • 33
  • 40
Alexandre Thebaldi
  • 3,796
  • 4
  • 27
  • 47
  • 7
    `Isset` is not a function: it is a language built-in. Using `isset` is faster than using a function. The other thing is that `isset` is used all over the place, so it makes sense that it's been profiled to death, whereas `===` maybe hasn't received as much love. – zneak Aug 13 '15 at 06:02
  • 2
    What is interesting is "isset" is used to check if the variable is there at all AND if it is not null, whereas the "===" operator is used to check if the two values are identical or not. You would think that the "isset" would be a few milliseconds slower due to checking two things where as the "===" only checks one. – Joshua Nightingale Aug 13 '15 at 06:08
  • `isset()` is just check variable is set or not. whereas `===` compare the value. Thats why isset is more efficient then `===`; I think both are different things. We use both for same function. – Prashant Tapase Aug 13 '15 at 06:49
  • 1
    Maybe it's related to fact that === checks if variables are same type – Ondřej Šotek Aug 13 '15 at 06:51
  • @PrashantTapase isset() checks if variable is not null too – Ondřej Šotek Aug 13 '15 at 06:52
  • http://php.net/manual/en/function.is-null.php#83588..... see difference in statements – Prashant Tapase Aug 13 '15 at 07:23
  • @zerkms that's not true - http://php.net/manual/en/language.operators.comparison.php or http://stackoverflow.com/questions/80646/how-do-the-php-equality-double-equals-and-identity-triple-equals-comp – Ondřej Šotek Aug 13 '15 at 07:57
  • @zerkms I'm not sure if I understand you correctly, but I'm trying these conditions: `if ( (int)1 === (float)1 ) print 'true'; else print 'false';` returns false and `if ( (int)1 == (float)1 ) print 'true'; else print 'false';` returns true. – Ondřej Šotek Aug 13 '15 at 08:09
  • @zneak You should post that as an answer, good explanation. – Oldskool Aug 14 '15 at 08:09

3 Answers3

4

The === comparison is a strict check, meaning that the two objects you're comparing have to be of the same type. When you break it down in plain English, it's actually not that weird that === needs some more time. Consider the parser to do this:

if (isset($var)) {
    // Do I have something called $var stored in memory?
    // Why yes, I do.. good, return true!
}

if ($var === null) {
    // Do I have something called $var stored in memory?
    // Why yes, I do.. good! But is it a NULL type?
    // Yes, it is! Good, return true!
}

As you can see, the === operator needs to do an additional check before it can determine if the variable matches the condition, so it's not that strange that it is a little bit slower.

Oldskool
  • 32,791
  • 7
  • 50
  • 64
  • 3
    `isset` also performs a comparison with `null`. Your explanation is kinda non-scientific. – zerkms Aug 14 '15 at 08:15
  • 2
    I've given this +1 because it does make the right point, although I do agree with @zerkms point as well. It's also worth pointing out to the OP that while one operation may be quicker than the next, neither can be considered slow; beware of the temptation to over-analyse stuff like this and do micro-optimisations, because it very rarely has any significant impact on the performance of your code. If you are looking to optimise your code, first find out where the real bottlenecks are, and put your effort into optimising those bits. – Simba Aug 14 '15 at 08:19
  • @zerkms True, I don't mean it to be a scientific proof. It's just an example to demonstrate that `===` needs to do some additional steps before it can come to a final conclusion. – Oldskool Aug 14 '15 at 08:22
  • @Oldskool the problem is that not only the number of "steps" matters, but also their complexity. In general "2 operations are faster than 1 operation" statement is not truthful. – zerkms Aug 14 '15 at 08:32
1

Isset is not a function: it is a language built-in. Using isset is faster than using a function.

The other thing is that isset is used all over the place, so it makes sense that it's been profiled to death, whereas === maybe hasn't received as much love.

Other than that, you'd have to dig in the PHP source with a profiler to see exactly what's going on.

zneak
  • 124,558
  • 39
  • 238
  • 307
0

I'm not sure I would call 100 million "a few iterations". You appear to have accumulated about a half-second difference, divide that by 100 million and you get a whopping 5 nanosecond difference per iteration if my math is correct. With the difference being so small it may simply come down to the fact that isset only has one operand in this context and === has two.

It's impossible to even discuss the Zend engine's implementation details of the two examples without specifying a specific PHP version; source code is a moving target. Even minute changes to the implementations are going to effect the results over that many passes. I would not be surprised if you found the opposite to be the case on some versions of PHP and/or in a different context.

isset itself is covered by three different op-codes in the VM depending upon the context:

"Simple" Compiled Variables like your example: ZEND_ISSET_ISEMPTY_VAR

Arrays: ZEND_ISSET_ISEMPTY_DIM_OBJ (requires 2 operands, the var and the index)

Object properties: ZEND_ISSET_ISEMPTY_PROP_OBJ (also 2 operands, var and prop name)

It's an interesting question for curiosity's sake but we're in hair splitting territory and it's probably not a real-world optimization strategy.

Phil Lewis
  • 61
  • 4
  • Other things can change given the context too. Checking `if( $var === 'foo' )` is likely to be a tiny bit faster than the example because the implementation under the hood can early exit with `false` the moment it sees that the two operands are not the same type. – Phil Lewis Aug 15 '15 at 08:09