ID:277613
Aug 23 2007, 1:46 pm
|
|
Since I'm used to programing my TI-84 calc, trying to make the code as "fast" as possible tends to be important to me. So, I was wondering, does an if statement slow you down if it's false?
Like, lets say I wanted to check something every time I moved. Move() Now, obviously that would be fine, but if I had 8 variables or even, say 80 to check, would that slow the code down? Also, does the validity of the statement matter? If the statement is false, will it slow the code down (and movement in general) or only if its true? (This seems pointless, but I'm making the kinda game that might need several such checks) | |
It depends on the statement: if(1 == 1) will be quite quick to compute, whereas if(34209595243 * 23445536 / 233284485 > 0) would obviously be slower.
It doesn't matter whether the statement is true or false (in terms of speed) unless it goes on to call other procs if it's true. If you're having to check 80 different things every time you move a character* you've probably designed that part of your game inefficiently. See if you can design something more efficient- and feel free to ask here again, too. What kind of game are you making, exactly? *edit: this probably applies more to if() statements than anything else, mind. 80 if statements is always going to suck. =P | |
"Do if statements slow you down?"
only around breakfast time, when i haven't had my orange-juice yet. | |
A little more than an else statement a little more than than the && operator. Honestly a chain of 1000 if statements shouldn't even be noticeable unless your computer is older than yourself.
| |
Elation wrote:
It depends on the statement: if(1 == 1) will be quite quick to compute, whereas if(34209595243 * 23445536 / 233284485 > 0) would obviously be slower. Thanks for the help. It's a Harry Potter game that I'm working on, Hogwarts: A History. (Obviously it's still pretty rough, but it's got over 30 spells already, and usually has about 10-15 people on, so it's not doing bad) A game like this is probably gonna end up with alot of random spell effects to check all the time. (80's an exaggeration, but you never know) | |
Chessmaster_19 wrote:
if I had 8 variables or even, say 80 to check, would that slow the code down? No. Put it this way: Modern CPUs run at several gigahertz. A 2 GHz machine executes roughly 2,000,000,000 CPU cycles per second. Each cycle typically executes up to several instructions (at least one). A branch is just one CPU instruction. How long it takes to test the condition entirely depends on the condition, but testing the truth of a variable is one instruction. So your if statement has just taken up around 2 of your 2,000,000,000 cycles for this second, leaving you 1,999,999,998 (oh no, how ever will we cope). Big deal! Stop worrying about it and get on with your programming. (This is not a completely accurate picture of the situation, but it's good enough for demonstration purposes. The fact that BYOND runs bytecode slows things down a fair bit of course, but nowhere near enough that you'd notice, even if you timed it with millisecond accuracy. In computer time, a millisecond passes with the slow glacial pace of eons. And I didn't even mention pipelining. But like I said, it doesn't matter; this is just to give you an idea of the scale involved.) Premature optimisation is the root of all evil. Write the code first. If it turns out to be too slow, then profile it to find out why. Only optimise the slow bits. Even when you do optimise, you will never need to optimise the individual statements; rather, concentrate on the algorithms involved. Everyone gets this wrong when they're starting out. As far as you or I are concerned, the only optimisation worth doing is big picture optimisation. (Do "the pros" occasionally do small-picture optimisation? Sure. Very, very, very, occasionally, if they're working in an environment that has the processing capacity of a rock. (Like an embedded system that runs at about 1 MHz, if you're really lucky.) But even then, they only do this after profiling the code, and only when they're absolutely sure that this function right here that's the problem, and only when it's being executed a million times per millisecond and people will die if it takes too long. Most professional software engineers never get into that situation, and probably wouldn't be able to handle it very well even if they did. You have to know a lot about CPUs - more than that, you have to know a lot about the exact type of CPU that you're using - in order to do low-level optimisation effectively.) | |
Infinite loops in the other hand...
If you are hung up about how long a process takes, try using Profile (under the Server menu of Options and Messages)