Home Tutorials Forums Articles Blogs Movies Library Employment Press Buy templates

Go Back   ActionScript.org Forums > General > Best Practices

Reply
 
Thread Tools Rate Thread Display Modes
Old 06-03-2008, 07:05 PM   #1
maskedMan
Obfuscated Coder
 
maskedMan's Avatar
 
Join Date: Apr 2008
Posts: 697
Default Which is most processor efficient?

So, there are a lot of ways to test equivalency. I'm trying to figure out which of these methods is the least processor intensive:

if(!x){}

if(x==0){}

if(x===0){}

I'm going to go out on a limb and guess that the last one is the least intensive, as it only checks *specifically* for a Number value of 0 rather than testing whether it is any of the following : 0, undefined, null, false

Am I correct in this assumption?
__________________
man.mask = mask_mc;

Sigh. The AS3 version just doesn't look at nice as
'man.setMask(mask_mc);'
maskedMan is offline   Reply With Quote
Old 06-03-2008, 11:52 PM   #2
ASWC
Site Contributor
 
Join Date: Dec 2007
Location: Vermont, USA
Posts: 3,179
Default

The three of them will have the same impact on the processor which is .... not very much!
__________________
aswebcreations
ASWC is offline   Reply With Quote
Old 06-04-2008, 07:30 AM   #3
yell0wdart
jordanrift.com
 
Join Date: Sep 2007
Location: Phoenix, AZ
Posts: 297
Default

I agree. You've probably got bigger things to worry about than how many cycles it takes any given CPU to compute a basic comparison. If speed is that big a concern, you're better off writing your app in C.
__________________

bad developer

Jordan Rift
yell0wdart is offline   Reply With Quote
Old 06-04-2008, 08:06 AM   #4
jsebrech
Joeri Sebrechts
 
Join Date: Apr 2005
Location: Antwerp, Belgium
Posts: 1,462
Default

I doubt that the last one is least intensive, because it has to do a type check and then an equivalency test. If the type is always a match, the type check is superfluous code.

If you really want to know, just test it. Build a set of loops to run each of these thousands of times, and measure the elapsed time.
jsebrech is offline   Reply With Quote
Old 06-10-2008, 07:30 AM   #5
BernzSed
oblivious
 
BernzSed's Avatar
 
Join Date: Apr 2006
Posts: 323
Send a message via AIM to BernzSed Send a message via Yahoo to BernzSed Send a message via Skype™ to BernzSed
Default

I'm going to go ahead and guess (though I could be wrong) that the first two end up getting compiled to the same bytecode.


You know, at a certain level, optimization of code become less important than readability and maintainability. Unless there's some big important reason to make this single statement take a nanosecond less to execute, just write whatever code makes the most sense.
There are some low-level coders out there infamous for writing code that's slightly more optimized than normal, but impossible to re-use because nobody can read it without getting a headache.
__________________
The views expressed in this post are those of an insane lunatic and do not necessarily represent the views of actionscript.org.
BernzSed is offline   Reply With Quote
Old 06-10-2008, 08:40 AM   #6
Flash Gordon
rather be programming
 
Flash Gordon's Avatar
 
Join Date: Feb 2005
Location: City of Angels
Posts: 10,000
Default

eh, who cares???

couple of big points that DO make a difference:

multiples of 256 for images can be automit mapped
image sized of 256 or less have faster support from the process.
and multiplication by .5 is faster than dividing by 2.
__________________
I'm old enough to know better and young enough to do it anyway. -- maskedman
Flash Gordon is offline   Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 06:27 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Ad Management plugin by RedTyger
Copyright 2000-2009 ActionScript.org. All Rights Reserved.
Your use of this site is subject to our Privacy Policy and Terms of Use.