I''ve been wondering on the fastest way to implement certain code, and I wondering what the code should (or shouldnt) consist of to make it fast. This is the list I thought would be the fastest instruction calls to the slowest. integer addition/subtraction integer mult/div float add/sub float mult/div logic (if statements) new class delete class function calls obviously less code is faster, but when wondering if deleting and creating new classes every frame or not would be a big hit on performance, I didnt really know. Would the size and number of the classes local variables affect how fast they take to initialize? A lot of questions, I know, but it would be really nice to know just what the relevent speeds of all these operations are. oh, and one more thing. How come everyone says that global var''s are bad? Thanks in advance -Fuzz

Creating and deleting classes is slow because your app is moving large chunks of memory arround (as opposed to setting variables in classes where you are just changing the data in a rather small chunk of memory). As for global variables, there is something about how they are stored on the memory stack, not sure exactly what, but as far as I can tell they aren''t so slow that you should make all your functions pass many variables back and forth (although if everything is in one class it is much faster to pass a pointer to that class than use a global variable declared as that class type). Hope this helps.

AirMouse

One of the major reason that global variables are bad is not due to any performance issues (I didn''t even know that there were any...) The big problem is that they are bad style. I know, I know, most game programmers could care less about style, but it really is important! The real problem is that they violate the priciple of information hiding and if you aren''t careful they can make debugging a real pain. Globals are ok for things that the ENTIRE programs needs to be able to access, but these types of things are few and far between. In almost every case, your code will be clearer if you use local variables at the propper scope and pass them only to the functions that really need to access them.

Check out the GPI project today!

Fuzz,
Global variables are bad because of their mailicious use of RAM. Aside from their bad style, those variables don''t go away (unless you free them...) and stay floating in memory from creation until finish of your program.
Logic statements are actually faster than the floating point operations, but not the integers. Also, don''t forget to use long/short type integers and also doubles where your program calls for. Unsigned bytes are also faster than the next step up (ex. an unsigned byte integer is faster than a signed short...) and don''t require any more memory than it''s type. Use your data types well, they conserve memory which will speed up any program. Especially with this memory hogging windows...
Oh, and function calls are actually the fastest of all the things you listed. They act just like a pointer to another section of code, then another pointer back. It''s actually very quick. If your functions are very small (About 3 lines of code or less) I would suggest to use an inline function. Depending on the program you might see a small performance boost, but maybe not. Those don''t boost speed much, and may cause your program to dramatically increase, depending on how many times it''s called.
One thing I do want to say though, and I don''t want this to sound mean. Try not to take offense. Unless your program deals with an insane ammount of mathematical operations, worrying about speed at this level is almost pointless. If you want more performance, you shoul try optimization of you code, starting with initialization code and moving up to the finishing line. The best way to squeeze performance out of an application is by optimizing it. And less code is not always better. If the base code is bigger, but better, the program will run 10 times better than the smaller code version...
Feel free to email me at scootr7481@aol.com if you have any more questions.

-- John d8?)

Sorry, above message was mine... Forgot to type my password...

-- John d8?)

"No, really, I DO know it all!" <-- Yeah, right!

Edited by - Scootr7481 on 4/5/00 5:01:28 AM

If you want to test the speed of those operations/functions, just loop them about 1000 times for every operation and calculate the time it took. I think the timeGetTime() API function should do, (milliseconds).

I''m really new to C++, but isn''t one of the biggest OOP features dynamic allocation of memory at execution time? That of course needs more programming and planning, but it sure sounds a lot better than the "old" compile time memory declaration, especially if you need big blocks of memory.

============================
Daniel Netz, Sentinel Design
"I'm not stupid, I'm from Sweden" - Unknown

If you have a profiling performance tool (not included with all compilers, though), you can time exacly how slow or how fast each part of your program actually is. It is a great way to find bottlenecks and helps decide what to optimize first.

FYI, in Visual C++ 6, the profiling tool is not available in the standard edition.

Eric Laberge

Thanks for all your help.

I was just thinking about the best ways to increase performance while reading some article (cant remember what it was now). But it was talking about how a random function was costly, and I realized I didnt really know how to optimize apart from the obvious ways.
Thanks again!
-Fuzz

It was said in an earlier post [anonymous Poster] that function calls is about the fastest in your list. This really depends on how many arguments the function call have.
To show this we have to look at the good old assembly. If you call a function with, say, 5 arguments, the caller have to push 6 dwords (ints) to the stack (current IP+variables). when the the function called is reached, 5 dwords are poped from the stack. With a pentium, push and pop use one clock cycle to be performed, and the call itself use from one to three cycles. So easy math says that we at worst use 14 cycles per call. would not be true because of pairings an things like that, but I think you got the idea.

btw: I don''t want to start a flame war with this post about assembly...

Tor M

About global variables: the only problem is that they use a fixed amount of RAM not efficiency. Using global variables is almost always fster than using pointers: with a pointer there is an extra calculation every time the processor wants to find the address of that variable in memory. With global variables there are fewer calculations to find that memory location.