Back to General and Gameplay Programming

Win32 vs C++ Runtime

General and Gameplay Programming Programming

Started by Turold July 09, 2008 11:02 AM

15 comments, last by Rydinare 15 years, 9 months ago

Evil Steve

2,021

July 09, 2008 11:47 AM

Quote:Original post by Terefere
How about allocations, considering speed on Windows only. HeapAlloc or malloc?

Considering malloc has substantially more debugging available for a minute speed hit, I really don't think HeapAlloc is viable.

You're really not taking things into perspective here - you're gaining a few cycles, a few tens or hundred at best. That's going to save you a fraction of a microsecond, which it's really not worth considering the portability and debugging you'll lose. What happens when you find you want to track all allocations to catch memory leaks in debug builds? You'll have to write your own memory manager which will do the exact same job of malloc.

If you do insist on doing this, then why stop there? Why not write a driver to bypass the OS memory allocation functions all together?

Rydinare

487

July 09, 2008 11:59 AM

Quote:Original post by phantom
Quote:Original post by Rydinare
The only times when you should go with a non-portable solution is if it's proven (not theorized) that the non-portable solution is significantly faster (a 2% difference is not significant) or much easier to implement. Even then, I suggest wrapping OS-specific things in a more portable layer.

Or the portable one can't do what the OS specific one can, for example Async IO can't be done with the portable C or C++ IO functions.

I do second the advice that it's often worth while putting a portable layer around such things; in general you'll want to add abstraction in software development not take it away [smile]

True on the asynchronous IO. That's a good point about functionality that just isn't provided in a standard way, so that should be in my list too. Overall, glad we're in agreement. [smile]

Turold

134

Author

July 09, 2008 12:04 PM

Quote:Original post by Evil Steve
What happens when you find you want to track all allocations to catch memory leaks in debug builds? You'll have to write your own memory manager which will do the exact same job of malloc.

If you do insist on doing this, then why stop there? Why not write a driver to bypass the OS memory allocation functions all together?

LOL, I already wrote a memory manager which does just that! Now, what kind of alloc call should I use in my overloaded "new" operator for max speed?

jpetrie

13,220

July 09, 2008 12:18 PM

malloc.

Turold

134

Author

July 09, 2008 12:30 PM

Thx. Rating up. :) Could you pls explain why not HeapAlloc? Isn't HeapAlloc "closer to the metal"? Btw, I plan to keep this MM in release build.

Evil Steve

2,021

July 09, 2008 12:59 PM

Quote:Original post by Terefere
Thx. Rating up. :) Could you pls explain why not HeapAlloc? Isn't HeapAlloc "closer to the metal"?

malloc() gives you more safety and debugging help (Like allocation hooks, etc). There's just no reason to use HeapAlloc.
Besides, if you use HeapAlloc, you'll need to create your own heap in addition to the default heap which will be less efficient (slightly).

Quote:Original post by Terefere
Btw, I plan to keep this MM in release build.

Why? Are you absolutely sure it is (or will be) more performant? Unless you've been doing low level coding for a long time, it's extremely unlikely that overloading the global memory allocation functions will be more performant - if you must, override operator new for specific classes, or create custom allocation functions for some types of memory, then you can use e.g. a pool allocator.

Rydinare

487

July 09, 2008 01:11 PM

Quote:Original post by Terefere
Thx. Rating up. :) Could you pls explain why not HeapAlloc? Isn't HeapAlloc "closer to the metal"? Btw, I plan to keep this MM in release build.

Be careful with the thought of "closer to the metal". When something is faster because it is "closer to the metal", it's often because you're losing something that the other feature is giving you. You might run into problems three months down the line, and wind up having to manually implement something that malloc was already giving you, and actually wind up performing slower in the long run.

Not to mention that, as mentioned earlier, the odds that your memory manager will improve upon the default in C++ is probably unlikely.

Win32 vs C++ Runtime

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Win32 vs C++ Runtime

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines