Whats faster? Check if key is pressed or calculate every frame

The common maybe professional way for using key inputs seems to be something like that:



I wonder if the more clearly "newby" way...



...is not probably even faster? Isn't it easier for the engine checking if the key is pressed every frame intead of calculating every time addforcecentral?

Of course it also depends on the command which is used for the calculating... So what's the best rule of thumb?

the best rule of thumb is to not worry about such stuff, write readable code and only optimize the bottlenecks.

pXent_addvelcentral() doesn't do much. it just changes the velocity of a body. it's like vec_add().
edit: it's the same with pXent_addforcecentral().

(your examples don't do the same thing if you press both buttons at the same time.)

Ups, you're right, has to be the force command of course (changed it)...

So you mean, if there is an effect then it is in such a way minimal that it can be uncared-for developing ?

I just think, if there are many parallel functions like this in the end ... the sum will make a difference to the faster code version !?!

The first method is of course faster in terms of CPU cycles because of two reasons:
1) The CPU doesn't have to check two times if a variable evaluates to true
2) The CPU only needs to call the function pXent_addforcecentral once, instead of two times. Calling functions isn't completely inexpensive as you first need to push the variables on the stack and then jump to a completely different memory region to continue the execution. Jumping back to the caller needs to pop a few variables from the stack and copy the result into eax, also not completely inexpensive

That said, it doesn't matter which way you choose as the time isn't measurable for a human (for really, really, high precision timers its measurable, but your brain will fail this challenge).

Hm, but the function is only called, if the key is pressed, isn't it!?! So normally only one key is pressed ... and all times when none of the keys is pressed, it has to call the function not at all.


-> my argument of "in sum" (à la "Die Summe macht's!") [haha, three languages in one sentence ] !?

go with:

even in sum the difference would be extremely small. the bottlenecks will be somewhere else.

or do you have to call the function ten or hundred thousand times per frame? you will first get problems because of other things then (entity count,...).

Why should that be faster? Should be similar to

and that would need more calculating than the second code version I posted.



That's a good point
The discussion is just focus on the question of the best and fastest coding algorithm you can do in general.
...cause if you have a really long program code with a lot of whiles it could become important if you use all the time the fast or slow method. Even if you use commands which are marked with "speed: slow" like c_move!

I like Quadraxas' code... unlike your second code with the two ifs, his pXent_addforcecentral is called a maximum of once even if both keys are pressed, whereas yours could be called twice if both keys were pressed.

I largely agree with ventilator though. When was the last time you experienced a slowdown because of too many ifs in a function? Or too many vec_sets? Worry about 65 entites who while(1) c_trace 5 times per frame.

Okay, but it normally makes no sense to press both keys - so this case will happen nearly never or only for a really short moment when the user switch the direction (key pressing).


Okay, imagine you have hundreds of characters, only moved by c_move if they can see you. Your two code options (both in a while) are:

or

... so, which one should be faster?
I guess the question is: Does c_move also cost "that much" CPU power when the result is that it doesn't move (like c_move(me, nullvector, nullvector, GLIDE)?

I don't know, c_move has that ominous "SLOW" tag on the manual page, especially with GLIDE, but that's a good question--how fast is it when no movement actually occurs? Probably the greater the distance the slower, as with c_trace, and probably the c_move function internally checks whether or not there is actually any distance, and if not returns early, so in this way it's internally optimized. I know all the movement examples I've seen, including the one in the manual (presumably written by JCL), c_move every frame without checking what the distance to be moved is.

So yeah, I'd be willing to bet c_move is written in such a way that it doesn't do anything at all if there is no distance to move. So both examples are exactly the same speed, with the exception of the first one arguably being infinitesimally slower because of if().