Can C++ memory leaks negatively affect CPU usage?

I have a C++ program that has a pretty terrible memory leak, about 4MB / second. I know where it's coming from and can fix it, but that's not my main problem. My program is taking up a very large amount of CPU usage and it isn't running as fast as I want it to. I have two different threads in the program. One by itself takes ~50% CPU, which is fine, and the other by itself takes ~15% CPU, which is fine. Together however CPU usage is 100% and the program cannot run as fast as it needs to.

Can a memory leak by itself cause a problem like this? I know the program will eventually crash due to the leaked memory, but does a memory leak immediately lead to a slower program? By immedi开发者_JAVA技巧ately I mean the program is too slow at the very start, not just when the memory footprint is huge.

Thanks!

Regardless of whether or not your memory leak is causing the problem it needs to be fixed. Once you fix the memory leak see if you're still having the problem. You should be able to answer your own question at that point.

Allocations in general can be slow and it sounds like you're doing a lot of them here. After fixing your leak, you will want to consider a pooled memory implementation to avoid thrashing your heap so much, especially in a multi-threaded environment.

It should not be a problem while you still have available memory. However, memory allocation is a relatively slow process, so depending on how often you do it, it might account for your problems.

Don't forget that a profiler is your friend for all and every optimization needs. It knows much better than you what your main bottleneck is.

Oh, and fix your memory leak now, while it's still easy.

Well, allocation is slow and does require at least some CPU effort to search for appropriate blocks to give. Besides that I wouldn't think so. It sounds like your program is in quite a mess so I wouldn't doubt that there's some larger issue at heart.

Have a look at your page faults. In Windows, use Task Manager, and in Unix/Linux try ps. It's likely that the extra processor time is being used to allocate additional memory to your process, and once the free physical memory has been exhausted, the OS has to swap out unused pages to the disk.

Another approach would be to use a profiling tool to see where the bottlenecks are in your code.

There are several angles here: 1) You have memory leaks. This is bound to cause page faults in your cache so data has to be sourced from RAM/disk. More I/O, more problems. Are you using a memory manager? If not consider using one. Look into dlmalloc for a start.

2) CPU usage 100% may not be due to this problem. Obviously the way to go is to first fix this leak and then use a profiler [Quantify is best, but costs. VTune is not bad, although I don't like the interface. Else gprof is not bad and its free.] and see which parts of your code is taking up CPU cycles.

3) I see that you are using threads. Syncing threads up is non-trivial. See if you are unnecessarily waiting for mutexes or something similar.

Disposing of previously allocated memory fragments should be relatively faster than their allocation and (as long as memory leak means "memory lost due to missing deallocation call") it shouldn't really affect your speed, only overall memory usage.

Although if you allocate huge amounts of memory every second and don't do proper deallocations, this could be the problem. I had the same issue when wrongly compiled gtkmm + librsvg leaked ~5 megabytes per second on screen redraw and that, of course, had some notable performance impact.

Of course, this doesn't mean you shouldn't eliminate your memory leaks if you know that they exist. Memory leaks could cause something more serious than performance troubles.