What could be the reasons that a C++ program runs slowly?

[dullboy]

The reasons I can think of that include running out of memory, time-consuming algorithm. What are other reasons? I assume this is not just for windows environment but also any unix-like environments. Any thoughts in-depth are appreciated.

[VictorN]

define "slowly"

[LoRd_MuldeR]

Running out of memory, doesn't make your program slow. Instead, memory allocations will start to fail at some point. And, if not handled gracefully, this will simply make the application crash.

If your application runs "slow", this could be because it is running time-consuming computations (CPU-bound application) or because it spends a lot of time waiting for I/O operations (I/O-bound application).

I suggest to use a profiling tool to analyze your program, which will tell you where in the code most CPU time is spent. And how much of the time your applications spends waiting for I/O...

[Arjay]

Poorly written code, like poorly written questions, can slow everything down.

[dullboy]

define "slowly"

It means it takes longer than normal. I just want to find out in general what might cause slowness of a program. It could happen in several situations. For example, the same program runs much slower today than the past few days. Thanks for your inputs.

[dullboy]

Running out of memory, doesn't make your program slow. Instead, memory allocations will start to fail at some point. And, if not handled gracefully, this will simply make the application crash.

If your application runs "slow", this could be because it is running time-consuming computations (CPU-bound application) or because it spends a lot of time waiting for I/O operations (I/O-bound application).

I suggest to use a profiling tool to analyze your program, which will tell you where in the code most CPU time is spent. And how much of the time your applications spends waiting for I/O...

Memory is not an issue for slowness? If a program takes huge memory to run in a PC, it will cause the PC to run very slow, right? Also would you give an example that it spends a lot of time waiting for I/O operations? What profiling tool would you suggest me to use in windows and unix separately? Thanks for your inputs.

[LoRd_MuldeR]

It could happen in several situations. For example, the same program runs much slower today than the past few days. Thanks for your inputs.

As said before, I think you first you need to find out whether your program is CPU-bound or I/O-bound.

In the former case, some other program that is running in the background and is using a lot of CPU time could be the cause for slow down. In the latter case, look out for background programs that keep the HDD busy.

And, if you are on Windows, in both cases the "Resource Monitor" (perfmon.exe) will be of great help to figure out which process is to blame. Especially have a look at virus scanner or indexing service

[LoRd_MuldeR]

Memory is not an issue for slowness? If a program takes huge memory to run in a PC, it will cause the PC to run very slow, right? Also would you give an example that it spends a lot of time waiting for I/O operations? What profiling tool would you suggest me to use in windows and unix separately? Thanks for your inputs.

Well, if your program access the memory a lot, it could happen that actually the memory bandwidth rather than the CPU becomes the limiting factor. But that doesn't usually happen, because CPU caches are very smart these days. Anyway, the sheer amount of memory that you allocate in your application shouldn't be that much of a performance issue! As said before, if you run out of virtual memory, your program will simply be unable to allocate more memory and thus subsequent memory allocations are going to fail (which means the program stops working!). If you run out of physical memory though (note: the virtual memory of all the processes running on the system can be many times larger then the physical memory!) the system will start swapping out memory pages from the physical memory to the swap file on your HDD. And that is what really may cause a slow down, yes.

(Use ProcessExplorer and look at the "Physical Memory" view in the "System Info" window. If all physical memory is used up, then indeed swapping may be the issue. You can also notice this by a sudden heavy HDD activity. For profiling your own application, i.e. to find the "hot" function(s) where most CPU time is spent, I'd use VisualStudio's built-in profile or the AMD CodeAnalyst on the Windows platform. On the Linix platform, I'd use GProf)

[razzle]

Any thoughts in-depth are appreciated.

Come on, you've been a member here for almost 15 years so of course you know all reasons a program may be slow.

Instead of playing this guessing game why don't you just tell us what your problem is?

[OReubens]

Running out of memory, doesn't make your program slow. Instead, memory allocations will start to fail at some point. And, if not handled gracefully, this will simply make the application crash.

if your application's working set becomes larger than (or close to) actual available RAM, then the OS will need to page out and page in memory. THis effectively makes your memory as slow as your harddisk. Actually running out of memory comes a LOT later when you are actually start exhausting the paging file. Well before that time your computer will have slowed down so much that it quite literally becomes unusably slow, so slow even that you can barely use OS features to kill the offending program.

The bad thing is that this kind of slowness impacts the entire system. Every single app, even OS features like trying to open task manager will become "unusable".

If your application runs "slow", this could be because it is running time-consuming computations (CPU-bound application) or because it spends a lot of time waiting for I/O operations (I/O-bound application).

Needing CPU doesn't make your app slow if that's what the app needs to do. Or do you mean poor/bad algorithms to solve a particular problem or poor/bad implementations of a right algorithm can make your app return results slower than expected.


IO doesn't make your app slow necessarily if that's what it needs to do. Again, it could be bad algorithms or inadequate hardware, but that's not the fault of the program.

I suggest to use a profiling tool to analyze your program, which will tell you where in the code most CPU time is spent. And how much of the time your applications spends waiting for I/O...

Most programmers don't know how to use profiling tools effectively. Or even worse, most don't even know how to make a profiling build.
Even if they do, they probably still won't have the expertise to look at the results and draw the right conclusions.
Profiling tools can show nothing at all and still your app could be slow.



you might want to clarify more in detail what you mean by "slow". because ultimately, your code will Always run at the same speed. being the clockspeed of your CPU.
slow to return result is not the same as low throughput which is not the same as responsivenss, which is not the same as 'system friendly' which is not the same as....

[OReubens]

Poorly written code, like poorly written questions, can slow everything down.

heh. THIS !!!
Going to make that into next week's mantra.

[dullboy]

Memory is not an issue for slowness? If a program takes huge memory to run in a PC, it will cause the PC to run very slow, right? Also would you give an example that it spends a lot of time waiting for I/O operations? What profiling tool would you suggest me to use in windows and unix separately? Thanks for your inputs.

Thanks so much for everyone's posts. I think memory could cause slowness of the program. If a program has a memory leak issue, then the memory becomes less and less. When it exceeds the physical memory but doesn't exceed the virtual memory, then the system has to swap pages from physical memory to HDD. From that point, read and write to the memory start to become slow. Correct me if I am wrong. Could anybody explain the issue with waiting for I/O operations? Thanks for your inputs.

[dullboy]

Come on, you've been a member here for almost 15 years so of course you know all reasons a program may be slow.

Instead of playing this guessing game why don't you just tell us what your problem is?

I think memory and poorly written algorithm can cause slowness. But I just want to learn more issues that could cause slowness. Thanks for your inputs.

[Arjay]

Could anybody explain the issue with waiting for I/O operations?

Sure. If your program has to wait on I/O operations, it is going to run slower.

[OReubens]

Sure. If your program has to wait on I/O operations, it is going to run slower.

a point of view thing I guess.
but this isn't necessarily a matter of code/a program running slow.
this is a matter of IO not being as fast as you want it to be.

This Could be a case of a bad approach to IO (such as reading a file 1 byte at a time), or a case of hardware limits trying to read a gazillion bytes and expecting this to be done in a yoctosecond.
yes, a yoctosecond is real a gazillion... not so much
or a case of having the bandwidth but bad latency.


And even if you have "slow io" is it a case of "slow code" or a case of "delayed results" or "insufficient throughput" or "unresponsiveness" or.....

People (especially end users) use 'slow' in so many different types of meanings it's often impossible to figure out what they really mean.


it's even worse when network "specialists" use it wrong and you can't even make it stick to them. I once had to explain for almost an hour to a guy why his "best possible" internet connection of 250MBit/sec was never going to work in his usage scenario because of high latency. "but my internet isn't slow, it's the fastest they (=the ISP) have. It's your program that's failing, so fix it." sigh... >.<


so again. please define "slow" more properly if you want a proper answer.