pouët.net

c++ or ++c ?

Thanks for the info guys. Preacher's example was very useful for me and basically answered my question.

Note that in all of my programm there are no long loops and come to think of it, I don't remember using any loops at all.

I also heard that the switch statement is generally faster than if. Maybe for keyboard events it is better to use the switch statement - to look for key codes. But maybe I won't bother changing the code now since it works alright.

hermes: why the sources are shouting? :(

They couldn't afford lower case letters back then. Also, everything was mostly in black and white because they'd just started inventing colors :/

"I also heard that the switch statement"

Louigi Verona, please stop here right now.

Mesure! Look at the assembly code! (With the compiler you're using)

Don't listen to people and their recipes. There is ton of obsolete information out there.

And optimization is not a set of magic practices that wizard teach you.

yeah good luck measuring those. maybe you should get an atomic clock for those measurements.

Decipher, your comment underlines something I also forgot to mention, which is that optimization is best done after having set some sort of goal. And anything that does not substantially help reaching that goal is useless.

Decipher, BECAUSE IT'S WRITTEN IN FORTRAN77!

no lowercase allowed :-)

that's not F77, that's some sort of assembler code.

but yeah, it's definitely transcribed from some punch-card by the looks of it :)

Yeah that's asm code for AGC processors.

I think it's some unique cpu too (AGC CPU)

http://www.ibiblio.org/apollo/

All this stuff is well and good, but replacing an if with a switch here and there will make virtually zero difference unless you're on a super slow processor or running it 1000s of times in a loop. Optimising the algorithm should always be the first stop.

I had to optimise some of my code recently, and managed to get it to >10x faster, and <10% of the memory usage, just by changing the algorithm. I didn't even bother to look at optimising things like if/else. (Of course, that's probably a result of my crappy initial code, maybe you're writing stuff efficiently first time :)

psonice: Well, in this particular case the algorithm is very simple and event based. As I've said, there is not even a single loop in the whole app. All I was concerned of were those if's and I got a reply. As for optimization, I understand what you say and this is good advice.

you worry too much man :-)
if speed is not causing you problems, then it probably isn't. don't forget that computers are ridiculously fast.

yeah, I really wonder how instead of just a well-deserved stop whining he got the tip to put branching hints in a freaking timer handler :)

as said many times in this thread: it's not fair to worry about such stuff in this context, if you do, just try to imagine the amount of things that your modern pc (<--) is doing BESIDES *your* program at that time ;)

now when there's actually something to optimize, these are good imho: http://www.agner.org/optimize/

I can't imagine how keyboard button checking can be a bottleneck. do you guys query input zillion times a second or what?

but if the character I'm typing is the last in the if-else chain!!!!111one!

OT, but.. If you follow good programming practice and only process events on the event thread and return quickly, guess what happens on android? :)

don't put your esc keydown check inside the tight inner inner inner loop that is called for every pixel and computed every frame. imagine if this caused a pipeline hickups every single time.

OMFG! *goes back to remove ESC check from inner loop* ;)

Good suggestion neoneye. I have another question for optimising those inner-inner loops though.. after I write each pixel, what's the fastest way to upload the texture with opengl?

Since this thread is obviously going down the drain as all threads do on Pouet, one last comment:

Not necessarily. Most compilers will generate little call tables if the switch only covers a small amount
of cases and the expression to be checked only covers a fairly linear amount of values. In the worst
case, your switch statement will be translated into many many IFs.

Anyhow, i guess __-_-___ sums it up pretty well. If speed becomes an issue, measure, read the
assembly code, see where the bottlenecks are and react then. If it's not broken, don't try to fix it ;-)

and try to use multiple threads with concurring inputhandlers to make the code even more fun

optimize: run; measure; think; modify; goto optimize;

rmeht, you have to write something new somehow in your loop otherwise you're just degenerating into producing a constant.