JavaScript: get rid of some if statements

[Charles Stover]

I was screwing around with Google's JavaScript compiler, and going over the code it outputs, when I realized something odd. I was trying to figure out how it worked, when it hit me.

So, here goes.
As you may know, if you do:
if (test && test2 && test3) alert("all three!");
Each condition is tested separately. If test is false, then it doesn't bother checking test2 or test3.
If test is true and test2 is false, it doesn't bother checking test3.

Knowing this, you can get rid of this if statement entirely.
Entire code:
test && test2 && test3 && alert("all three!");
Parsed, this is the same as putting:
true;
It returns true, but it does nothing with it, so nothing is output or noticed.
It tests whether or not test, test2, test3, and alert() are true. alert() is always true, but it wouldn't matter anyway, since it's the last thing called. true; and false; have the same effect (nothing). What matters is whether or not the first three are true.

So, in the mind of JavaScript:
test && test2 && test3 && alert("all three!");
Is test true?
N: stop testing the rest
Y: is test2 true?
N: stop testing the rest
Y: is test3 true?
N: stop testing the rest
Y: is alert("all three!") true? // this will actually alert the message
N: return false
Y: return true // doesn't matter, 'cause the returned value is ignored

My previous code:
if (this.getAttribute("value")=="Search") this.setAttribute("value","");

Compressed code:
this.getAttribute("value")=="Search"&&this.setAttribute("value","");

Hope this is helpful. Not exactly standards, but it apparently works cross-browser enough for Google to use it. I don't plan on changing my code to do this (i.e. when I make it), but I do plan on using their compressed code for public scripts. Just figured you guys would love the nerdom within it.

[Jordan]

That's pretty interesting and it makes sense, but I don't think I'll be using it. I can understand why Google would want to compress all of their code since they use so much bandwidth and saving a few characters might actually save money in the long run (if that's even the reason for doing that).

[Charles Stover]

After discussing it with someone, we've concluded that this probably makes code execute faster as well! It surely should be benchmarked.
Since an if statement has to wait for the returned boolean and then check the value of the boolean, it theoretically would take longer to do (because of the value check of the final boolean). This is compared to the posted method that will execute ASAP and the boolean returned doesn't matter.
It would execute before the boolean returns, as opposed to after, and eradicate the middle man of checking whether or not the returned boolean is true or false.

[Jordan]

Dec 8, 2009 23:30:38 GMT -8 Charles Stover said:

After discussing it with someone, we've concluded that this probably makes code execute faster as well! It surely should be benchmarked.
Since an if statement has to wait for the returned boolean and then check the value of the boolean, it theoretically would take longer to do (because of the value check of the final boolean). This is compared to the posted method that will execute ASAP and the boolean returned doesn't matter.
It would execute before the boolean returns, as opposed to after, and eradicate the middle man of checking whether or not the returned boolean is true or false.

Another good point which I was thinking about myself, but it wouldn't make a noticeable difference unless it's being executed thousands of time in a loop or recursive function. If it is, though, then it would be very nice. Have you timed it yet?

Edit: Just ran some tests and it is faster.

Edit 2: The results below are wrong, read the next posts.

Using If	Without If
3.338		2.969
3.266		2.949
3.243		2.814
3.292		2.832

<script type="text/javascript"><!--

var time = [(new Date()).getTime(),0];

var test1 = true;
var test2 = true;

var x = 1;

while(x <= 1000000000)
{
      /*if(test1 && test2 && x)
      {
            x++;
      }*/
     
      test1 && test2 && x++;
}

time[1] = (new Date()).getTime();
document.write("Time: " + (parseInt(time[1] - time[0])/1000).toFixed(3));

//--></script>

[SuperSleuth]

I had actually started doing this in the past (scripting for InvisionFree), but I remember running into a few problems with it in larger scripts.

Cool to know it's faster than using if() statements though.

[Charles Stover]

Dec 8, 2009 23:59:04 GMT -8 Jordan said:

Dec 8, 2009 23:30:38 GMT -8 Charles Stover said:

After discussing it with someone, we've concluded that this probably makes code execute faster as well! It surely should be benchmarked.
Since an if statement has to wait for the returned boolean and then check the value of the boolean, it theoretically would take longer to do (because of the value check of the final boolean). This is compared to the posted method that will execute ASAP and the boolean returned doesn't matter.
It would execute before the boolean returns, as opposed to after, and eradicate the middle man of checking whether or not the returned boolean is true or false.

Another good point which I was thinking about myself, but it wouldn't make a noticeable difference unless it's being executed thousands of time in a loop or recursive function. If it is, though, then it would be very nice. Have you timed it yet?

Edit: Just ran some tests and it is faster.

Using If	Without If
3.338		2.969
3.266		2.949
3.243		2.814
3.292		2.832

<script type="text/javascript"><!--

var time = [(new Date()).getTime(),0];

var test1 = true;
var test2 = true;

var x = 1;

while(x <= 1000000000)
{
      /*if(test1 && test2 && x)
      {
            x++;
      }*/
     
      test1 && test2 && x++;
}

time[1] = (new Date()).getTime();
document.write("Time: " + (parseInt(time[1] - time[0])/1000).toFixed(3));

//--></script>

But if you think about it, every if statement is recursive and repeated thousands of times. The times are just spread out amongst multiple page loads. If you're using a script that is accessed by more than one person at a time (i.e. any large site), this is useful. But, that would be for server-side code, since the JS isn't executed until client-side and thus wouldn't be noticeable to anyone lest it was repeated often within that same page as you said.
But I can't wait to see how well this works in PHP.

[Chris]

Jordan: Question on the test:

How do the results change for you if you use

/*if(test1 && test2)
{
x++;
}*/

instead of

/*if(test1 && test2 && x)
{
x++;
}*/


I think that extra check might make the difference. Just maybe. However, I also know that it wouldn't be the equivalent if statements otherwise. (I'd run the test myself, but I'd rather have consistent testing on one computer.)




Charles: o.O Nice trick. I like it. I may use it if I need to compress code, but for my own personal stuff I'll stick to writing out my IF's.

[Jordan]

Good catch Chris, I actually started thinking about after I logged but didn't care enough to come check it. Turns out it's a huge difference.

Using If
2.720
2.821
2.839
2.812

W/O If
2.759
2.817
2.748
2.816

You should try it on yours to see if you get the same kind of results.

[Charles Stover]

Looks like you'll have to boost the number of times it ran to tell which is going faster.

[Jordan]

In FireFox, it looks like it's interpreted the same.

This was to ten billion.

89.134
88.959

88.858
89.159

[Charles Stover]

What about other browsers? IE specifically. Chrome and FF both have epic JS engines.

EDIT:
Oh, oh, and PHP would probably be more telling.

[Simie]

Dec 9, 2009 22:46:22 GMT -8 Charles Stover said:

EDIT:
Oh, oh, and PHP would probably be more telling.

I bet PHP will give a syntax error.

It doesn't even allow this...

explode('blah', $someString)[0]

[Charles Stover]

I know. I've always hated that. But there's only one way to find out.