Performance really

Ah! This is actually much more informative than the other site I had. Thank you!

wow, there were a lot of examples...I had been thinking about running some similar test myself to see what kinds of things took a long time...most to check for, do/wile, etc to get the best one ya know, but this will save me countless hours...I think a lot of the games I am wanting to do...I can pick and chose where to worry about performance...and where to let it slide...looks like the switch block for 8-way D-pad...4-way w diagonals checked using AND statements, would be way faster than using if/elses...especially if you add in buttons, like holding straight down and hitting jump to drop a from a platform...and conditionals based on states...lotta places to worry about performance...

I'm going to come out and say it and please don't take offense but I always get frustrated when I see people being so concerned about these intimate performance details and ignoring the big picture -

Don't sweat the microsecond difference between a switch statement vs. an if-statement until you've actually tuned the slow spots in the code. You guys are getting really into the intense nitty-gritty and potentially ignoring major performance sticking spots.

Make your code clean and elegant, using the appropriate constructs where needed and don't stress the minute tuning issues initially. Once you have it working and playing properly then you can go back in and determine if it needs to perform better and where.

In practice, the logic itself is the performance problem, not the code constructs. For instance, some heavy-handed collision detection will cost you more then those if-statements ever did.

Anyways, enough harping from me. Have fun!

Quote:

---

Originally Posted by webgeek

I'm going to come out and say it and please don't take offense but I always get frustrated when I see people being so concerned about these intimate performance details and ignoring the big picture -

Don't sweat the microsecond difference between a switch statement vs. an if-statement until you've actually tuned the slow spots in the code. You guys are getting really into the intense nitty-gritty and potentially ignoring major performance sticking spots.

Make your code clean and elegant, using the appropriate constructs where needed and don't stress the minute tuning issues initially. Once you have it working and playing properly then you can go back in and determine if it needs to perform better and where.

In practice, the logic itself is the performance problem, not the code constructs. For instance, some heavy-handed collision detection will cost you more then those if-statements ever did.

Anyways, enough harping from me. Have fun!

---

Probably the best advice yet in this thread :)
He's right, don't concern yourself with very minor things like switch/if since there's probably much bigger things slowing your game down you should be focusing on.

It is interesting though to see speed comparisons for various things like that, good link :thumbsup:

Yeah, I used to build on performance more than how it would actually work. It is nice to get something done that works without worrying about performance. Especially when the code runs easy enough to do without any optimization.

Quote:

---

Originally Posted by webgeek

I'm going to come out and say it and please don't take offense but I always get frustrated when I see people being so concerned about these intimate performance details and ignoring the big picture -

Don't sweat the microsecond difference between a switch statement vs. an if-statement until you've actually tuned the slow spots in the code. You guys are getting really into the intense nitty-gritty and potentially ignoring major performance sticking spots.

Make your code clean and elegant, using the appropriate constructs where needed and don't stress the minute tuning issues initially. Once you have it working and playing properly then you can go back in and determine if it needs to perform better and where.

In practice, the logic itself is the performance problem, not the code constructs. For instance, some heavy-handed collision detection will cost you more then those if-statements ever did.

Anyways, enough harping from me. Have fun!

---

This is right of course. If you're brute forcing collisions or something silly like that which most actionscript programmers have done one time or another, you should be worrying more about making your game run as efficiently as possible with good design and code and after that maybe start looking into the difference between commands.

If you're running most of your stuff in EnterFrame then just don't even bother with command optimization.

I must admit that I did get very good results when changing for...next to do...while in my rendering method. Like 5fps. But I still use for loops in everything that doesn't run constantly because it looks better.