What imrpoves performance in memory management? By using the keyword New or malloc? What if one allocated memory doesn't get deleted - will it literally screw the memory leaving it too fragmented or after the computer restart the memory will automatically free anything it has resides?

New and Malloc are termed as Heap, right? Stack Heap, Pool Heap - etc?

Have a great day everyone! I wanted to know about your perspective on better performance in memory.

What imrpoves performance in memory management? By using the keyword New or malloc?

Doesn't matter (or at least it shouldn't). If you're using C++, use new.

What if one allocated memory doesn't get deleted - will it literally screw the memory leaving it too fragmented or after the computer restart the memory will automatically free anything it has resides?

On a modern system, the OS will free all "un-freed" memory when the program terminates, so you shouldn't need to restart your memory to reclaim the un-freed memory. But it's still bad practice and can lead to your program running out of available memory while it's executing.

New and Malloc are termed as Heap, right? Stack Heap, Pool Heap - etc?

new and malloc allocate memory on the heap.

Have a great day everyone! I wanted to know about your perspective on better performance in memory.

The best memory performance will come from allocating and freeing as little as possible. If you can re-use a chunk of memory, that's better in terms of performance than freeing it and reallocating another chunk. Allocating memory is a very slow and expensive operation. Accessing memory is quite slow too, unless it's in the cache, which is why cache-misses and cache performance are often a critical bottleneck in modern applications (so try to maintain some temporal and spatial locality when accessing memory to improve cache performance).

New and malloc are both used for dynamic memory allocation on the heap, new is C++ specific while malloc is available in both C and C++. Mixing of both new and malloc in C++ is heavily discouraged, so it's best to stick to the new keyword for standard dynamic memory allocation in C++.

Not releasing memory with free or delete causes what we call a memory leak when said memory becomes unreachable (ie. the application has no access to a pointer which points to this memory). The memory is now unavailable for use by both your application and the operating system, and thus cannot be reassigned to another application for as long as the original application is running.
When the original application exits however the operating system will reclaim all memory allocated by that application. This however does not mean that you shouldn't take memory leaks seriously as they are still potentially hazardous.

Memory fragmentation is an issue which will occur in standard dynamic allocation whether you have memory leaks or not, chunks of memory which are all allocated in one new or malloc call however will be contiguous in memory. The only way to completely remove memory fragmentation is by doing linear allocation on a pre-allocated memory pool for example (like when working with the stack), but this allocation scheme is absolutely not suited as a general purpose allocator.


These concepts are all very elementary C++ concepts. I know you're writing a game engine, so I find it very odd that these things are new to you.

Try to avoid new or delete. Allocating memory from a pool of heap is a very slow operation.
Automatic variables are much faster

New and malloc are both used for dynamic memory allocation on the heap, new is C++ specific while malloc is available in both C and C++. Mixing of both new and malloc in C++ is heavily discouraged, so it's best to stick to the new keyword for standard dynamic memory allocation in C++.

Not releasing memory with free or delete causes what we call a memory leak when said memory becomes unreachable (ie. the application has no access to a pointer which points to this memory). The memory is now unavailable for use by both your application and the operating system, and thus cannot be reassigned to another application for as long as the original application is running.
When the original application exits however the operating system will reclaim all memory allocated by that application. This however does not mean that you shouldn't take memory leaks seriously as they are still potentially hazardous.

Memory fragmentation is an issue which will occur in standard dynamic allocation whether you have memory leaks or not, chunks of memory which are all allocated in one new or malloc call however will be contiguous in memory. The only way to completely remove memory fragmentation is by doing linear allocation on a pre-allocated memory pool for example (like when working with the stack), but this allocation scheme is absolutely not suited as a general purpose allocator.


These concepts are all very elementary C++ concepts. I know you're writing a game engine, so I find it very odd that these things are new to you.

Yes, I understand the concepts are elementary - within 3 months now I've been refreshing my knowledge in C++. I've not touched C since I was 7 years old. Teenage years I've been mostly in HTML, PERL, and other web-based programming. 2001-2011 I've been not programming because getting over depression and couseling sessions. 2011, met my wife and happy as a clam. So, yes; I'm refreshing quickly as possibly to catch up with the professional game industry. It's not crazy to remember pieces of code from a dream. I woke up last night from a dream discussing about TCHAR with another person in my dream. Guardian Angels sending some kind of crytic message - who knows. All I know is I got to catch up to the professional game gurus. This is why I'm obtaining every bit of information possible - John just didn't wake up and say "Doom - 3D first game engine. I have all the code inside my brain." He had to learn it from books; from others; from other sources and trial and error. Albert Einstein was perhaps showed the formula that would equate to E=MC squared. I'm a spiritualist; my views may differ upon others spiritual views on the forum.

Try to avoid new or delete. Allocating memory from a pool of heap is a very slow operation.
Automatic variables are much faster

Define automatic variables (I assume you're talking about using the stack?)

It's definitely true that allocating on the heap can be slow, but completely abandoning dynamic allocation sounds quite drastic to me, and is mostly easier said than done.
The important thing is to find a correct balance between stack and heap usage, and to know which situations call for stack allocation and which call for heap allocation.

Also, allocating from a memory pool doesn't have to be slow, it's all dependent on what kind of allocation scheme you use. It's perfectly possible to do very fast stack-like allocation on a pre-allocated memory pool. There's an interesting paper from DICE about this which can be found here


@SIC:

There's no need to drag spirituality into this, I'm just saying that it might be a good idea to start off with something less complex and gigantic than a game engine + tools when you need to get reacquainted with basic C/C++ concepts.

So, a rule of thumb is to consistantly make sure no memory leaks because it can cause performance slow down. Got it. Additional notes, keep proper heaps so there's less fragmentation in memory - got it.

The memory is now unavailable for use by both your application and the operating system, and thus cannot be reassigned to another application for as long as the original application is running.

This is not really true on desktop operating systems. In practice, when some other process needs more memory than is currently available, the virtual memory system will stash a few of your memory pages to disk, and grant that physical memory to the other process. Obviously, this is all pretty transparent to both applications.

On a console or mobile device, there often isn't a virtual memory system, in which case your statement is correct.