How do you make programs run faster

[EwCjE3v7]

Is it about the code? Like less definitions will make the program faster? Or something else?

[N36fSL3A]

Optimization. Try to reduce memory usage (use shorts or chars instead of ints where not needed), maybe add the construction of a certain object outside of a loop instead of inside.

[htirwin]

It's usually the algorithm's that make the biggest difference and usually your algorithms revolve around your data structures.

First thing is to use the best data structures for the job.

use shorts or chars instead of ints where not needed

Actually I do not think this will increase the speed at all. It is possible it may actually reduce the speed depending on the architecture.

I know at least that when I was doing a little bit of openCL programming, I learned that on the GPU, using ints increased performance over shorts or char.

Usually there is one or two things that disproportionally reduce performance (the bottlenecks).

[giblit]

I would agree with Htirwin with the algorithms affecting it the most. Algorithm a will take 1000 iterations and finish fast and algorithm b may take 100,000,000,000,000 iterations and will take a VERY long time to finish. If you ever try project euler you will need to find the best algorithm for each problem. Brute force does not work on most problems.

[Catfish666]

Alongside the choice of algorithm, data structures can also improve the program's performance.

C++ already offers some very useful data structures and ADTs, implemented as containers in the standard library, for example: std::unordered_map, std::map, std::priority_queue.

Sometimes you'll go a step further and implement a custom data structure for your program.

If you want a "real" example of how data structures affect performance, consider this article on LZW compression:

http://www.cplusplus.com/articles/iL18T05o/

[EwCjE3v7]

Yea I heard, that sometimes when working with a big type in another funtion.. Instead of duplicating it, just make a const int reference to it. But duplicating does have its own ups as in changing the other type but not the original

[TwilightSpectre]

Yes, the whole passing by value vs. passing by reference problems - normally you'll prefer passing by reference, but as you said, in some cases passing by value can have it's merits (such as when you would need to copy and modify the value passed anyway).

Another thing that many people don't realize is the problem of data locality and cache misses. For this reason, for example, storing objects in an array (C-style, std::array or a std::vector, which all store elements contiguously) can speed up your program due to it not needing to keep retrieving data from RAM, and waste hundreds of CPU cycles doing so.
Nowadays bottlenecks are mostly on the memory usage and loction rather than the CPU time, though of course a bad choice of algorithm can quickly reverse this trend.

Another technique is to use custom allocators, such as allocating a block of memory at the start of your program and simply 'giving out' blocks of this memory to objects that require dynamic allocation instead of using ::operator new, which can be very inefficient when doing lots of allocations.

There are lots of things to do with optimization, but the most important thing is don't optimize for the sake of optimizing - use a profiler to find the bottlenecks in your program and fix it, though obviously you should still create your program with efficiency in mind.

[MiiNiPaa]

use shorts or chars instead of ints where not needed

Actually I do not think this will increase the speed at all. It is possible it may actually reduce the speed depending on the architecture.

There is {u}int_fastXX_t family of types. Which can be useful from perfomance standpoint.
There is {u}int_leastXX_t to reduce memory usage.

Another thing that many people don't realize is the problem of data locality and cache misses

I agree. It is often overlooked and insanely hard to detect.

Worst bottleneck you might find is that happens because of your program architecture. Do not underestimate importamce of designing your program. Do not rush into and start coding. Many pitfalls and future problems can be avoided by careful planning.

Two rules when writing code:
Do not prematurely optimize your code
Do not pesimize your code

[rapidcoder]

Nowadays bottlenecks are mostly on the memory usage and loction rather than the CPU time, though of course a bad choice of algorithm can quickly reverse this trend.

My limited experience tells me something totally opposite. In all the benchmarks I saw (including gaming benchmarks) using faster/lower-latency RAM almost never translates to such performance gains as using faster CPU. Memory performance is important, but CPU is much more important IMHO.

You're right that memory locality is one of the factors impacting performance, but you overrate its impact. In fact, you're very unlikely to gain more than 2x from memory locality optimisations, even though a cache miss costs so much. This is because CPU designers are not idiots and they know cache misses / branch mispredictions are costly and they have put a whole lot of circuitry into modern CPUs to avoid it. Therefore, even traversing a linked list, which may seem terrible performance-wise, might not be that bad compared to traversing a vector, because CPU will do appropriate prefetching. At the time your item arrives in CPU register, even before CPU starts to do some logic on it, the next item is already half-way being fetched, much earlier than you request the next item in your program.

[TwilightSpectre]

I presume that different people will have different experiences, but this is what I have found:

For professional games, etc, a better CPU will improve the speed more than an improved RAM - in fact, this is often true. Not only because most games nowadays are build with data locality in mind, but because better CPUs might have a larger bandwidth (more data at once) and larger cache sizes (more data closer to be processed). The larger the cache, obviously the less mispredictions hurt - though they still hurt. I wrote a quick program w couple of months back to test this, using a std::list and a std::vector, and it demonstrated an improvement of 27 times improvement on my computer. I'll post the program if I can find it.

Anyway, even double the performance is still a lot. Though, this is just my experience - other people might have had different experiences, and my knowledge of hardware, and associated optimizations, though decent, is nowhere near an expert level.

[Mats]

There are hundreds of answers to this question, but I think the single most important thing is to find the appropriate algorithm for what you're trying to do and then spend time thinking about how to implement (and perhaps modify) this algorithm well, rather than just rushing into making it in an inefficient way. The more time I spend coding, the less time I am spending typing and the more time I am spending thinking before I type. It seems like this should get the job done slower, but actually, spending that extra time to consider your options and how to go about the job definitely makes the coding faster and the end result much better.

[CodeGazer]

As to the original question of how to optimize your programs I think a very important thing to note is only optimize your programs when you need to. I know a lot of people will read that as you can write sloppy code which is not what I am saying by any means.

What I mean is write code as best you can performance wise but don't spend days or months trying to optimize something that in the end will have little to no effect on your program as a whole. There is just no reason to do so and you will just be wasting development time that could be spent on something of much greater importance.

Personally I write code as best I can performance wise and don't worry about optimizations until I hit a point where they are needed. This point differs greatly from project to project, but let's take a game for example because that is what I am most familiar with. When coding a game I don't even bother with optimizations (Again not saying to write sloppy code) until a good chunk of the project is already finished and I start to see that the frame rate is dipping pretty low, or I am getting jittering in the loading of resources. In my opinion there is no point doing optimizations before then.

Also when you do start doing your optimizations don't just jump around blindly optimizations things here and there and don't try and optimize everything in your code. Make sure you run a profiler on your program! This will tell you exactly where optimizations will give you the best rewards. I usually try and stick to the 90-10 or 80-20 rule, which basically means you will optimize the slowest 10% - 20% of your code. Run a profiler find out where the major bottlenecks are and start optimizing them until you meet your needed performance criteria.

As for what optimizations you can do that really all depends on the situation and your project. Everyone else in the thread brought up great points, especially cache misses which like others have said are not talked about a lot.

For example you might need to optimize your networking code which might require figuring what data out of the data that you are already sending over the network you can get rid of to reduce the bandwidth. Then there is threading optimizations if your program is multithreaded. Or maybe you are managing your memory badly and need to reduce cache misses. The list goes on and on and it would be almost impossible to list all of the possible optimizations you could do.

But to recap my advice would be this.

1 - Don't optimize when you don't need to! There is such a thing as optimizing your program to much, so only do so when it is needed otherwise you are wasting your development time which could be put to better use.

2 - Don't optimize your program to early. If you start trying to optimize your project when it is still very early into development there is a very good chance that (Among other reasons) you might decide later that you don't need what you just optimized and get rid of it (Wasted development time). Wait to do full blown optimizations until the project has matured a bit and when you are actually seeing performance concerns.

3 - Don't optimize blindly, run a profiler! This is probably the most important thing. Running a profiler on your program will tell you exactly where your optimization will do the most good.

4 - You don't need to optimize all of your code, usually doing something like 90-10 or 80-20 (Optimize the slowest 10% - 20% of the code) will do the trick and get you to your performance goals.

These are all just what I believe when I set out to optimize my programs and are by no means a how to guide and I am sure others will have different opinions then me. But hopefully this helped a bit.

[rapidcoder]

It is very important to get architecture right. This will be the major factor determining how good you can eventually optimize your program. Therefore, really do think about performance when *designing* your program.

E.g. even if Cassandra was coded in Ruby or Python, and MongoDB in hand tuned assembly, Cassandra would always be faster for huge loads. Architecture matters a lot.

[CodeGazer]

rapidcoder wrote:

It is very important to get architecture right. This will be the major factor determining how good you can eventually optimize your program. Therefore, really do think about performance when *designing* your program.

I definitely agree, a bad architectural design can severely hamper a project before it even starts.

[Computergeek01]

Then there is threading optimizations if your program is multithreaded.

Thanks, but I think I would rather donate bone marrow then go through that again. If there are any lessons that I've learned from thread optimization it's that threads are not the super awesome programs within a program that they seem to be the first dozen times that you use them and even though processors these days are specifically designed to accommodate them, that does not mean that the rest of the system is. Don't relay on threads unless you have some very simple task that absolutely must be done concurrently with your main program and then make damn sure that it is a stand alone task.

@ OP: The point I'm trying to make with my little rant above is that even though it is the correct thing to do; at certain times optimizing your code is simply not worth the effort regardless of time constraints. Good enough is often times good enough.

[chrisname]

rapidcoder wrote:

Cassandra would always be faster for huge loads

I had to contain a snigger at this.

[ResidentBiscuit]

How do you make programs run faster?

Completely get rid of loops and recursion. Decrease your LoC.

[Computergeek01]

*Deleted* This was probably something that would go on it's own thread.

[angiemailo]

If there is no way to fix your code (which you did not provide) to make it run faster, then there is only one way I can think of. In Task Manager, under the applications tab, right click your application then click go to process. Right Click the process, then set its priority to "realtime". This will direct more processor attention to your application, however, this means less goes to the Operating System. You must be careful when messing w/ processor priority. I have recieved the dreaded "stop error" because of it before. If this is not what you were looking for, plese provide what code you have written so that people here will know what you have done and how they can help.

[Duthomhas]

RE realtime priority

Don't do that!

You'll wind up making your whole system less responsive.
http://blogs.msdn.com/b/oldnewthing/archive/2010/06/10/10022675.aspx