Making Code Faster

[falco85]

What methods do you guys use to make your C++ code faster? I've created a small query statement which I can't share but it executes very slow and uses more resources than anticipated. What can I do to make it faster?

[WingedPanther]

Check optimization settings on your compiler, or try a different compiler, to start with.

[AsmDeveloper]

I think that the best method of this is use profilers. Examples: AMD CodeAnalyst, Intel VTune.

[falco85]

I've never heard of any of these profilers. What do they do?

[FlyByWire128]

Originally Posted by falco85

I've never heard of any of these profilers. What do they do?

They'll analyze your program (code) and find out where the bottlenecks are. It's pointless to work on optimizing code just by looking at it, because something you think is difficult and something your computer thinks is difficult can be very different. Lots of things that seem very simple can run in O(n^2) or higher times. My last CS class made a big deal out of this stuff. Your program is only as fast as the slowest part of code, so until you know that, it's pointless to try to optimize the rest.

Hope this helps.

[Deathcry]

just find places in your code to be optimized.
like instead of

while (n-- > 0) {
*p = 0;
p++
}


it could be something where it doesent have to do so many things like this


while (n-- > 0)
*p++ = 0;


this isnt the only way to optimize your programs. you can find various books/ebooks on the subject.

just googled heres some links
C++ Optimization Strategies and Techniques
Optimizing C and C++ Code

u can also get books like this one
Amazon.com: Code Optimization Techniques for Embedded Processors - Methods, Algorithms, and Tools: Books: Rainer, Leupers

[taskiyu]

I used your net send program it was very god like!

[Code Goddess]

like instead of

while (n-- > 0) {
*p = 0;
p++
}


it could be something where it doesent have to do so many things like this


while (n-- > 0)
*p++ = 0;

That has exactly the same number of operations. I would expect a good compiler to produce exactly the same machine code from both snippets. In fact, it's possible that a compiler would have more trouble optimizing the compact code. Fewer lines doesn't mean faster. The first example could be "optimized" like this:

while ( --n >= 0 ) {
  *p = 0;
  ++p;
}

This assumes that n is a signed integral type. The prefix increment and decrement are logically more efficient than the postfix because temporary storage isn't required, but that's still pushing it because I don't know of a compiler that can't optimize those into equivalent machine code.

Ideally, you would optimize this loop by deferring to a library function that's heavily optimized for the system:

memset ( p, 0, n * sizeof *p );

You're more likely to get good results from a change like that than silly micro code optimizations that your compiler already does for you. Those kind of optimizations were okay two decades ago, but now you don't want to sacrifice clarity for dubious tiny increases in speed. Better yet, use smarter algorithms. That's where the biggest hits to performance come from.

Also, keep in mind that you can optimize your program all you want, but unless it's code bound, you're not going to get much improvement. If you spend most of your time waiting for results from a user, network connection, database, or pipe, it doesn't matter how fast your calculations are. The perceived performance is determined by the slowest link.

[WingedPanther]

One of the first rules of optimizing is: let the compiler do it for you.
You are more likely to get mileage from making sure you have an efficient algorithm (such as O(ln(n)) vs O(n^2)) than from trying to do minor tweaks. Also, be aware of WHERE you are getting the most slowdown in your code. If your code runs slow because it does a ton of disk access, optimize there, not in the memory management.

[thormj]

Is this query an SQL query, or a C/C++ algorithm or ?

A lot of issues with using SQL can be solved by using the correct indices.

For C/C++, I usually end up single-stepping through the code through some test cases to see if I forgot something and the code is doing something I didn't expect (or that I see is stupid;

eg, one (obvious & piggy) way compute a rolling average:

for(i=0;i<buf_size;i++)
  if(i> roll_size)
    {
    for(j=0;j<roll_size;j++)
       sum+=input[i-j];
    output[i]=sum/roll_size;
    }
  else
   output[i]=input[i];

(err... slow!!!)
--
better way:

sum=0;
for(i=0;i<roll_size;i++)
  {
  sum+=input[i];
  output[i]=input[i];
  }

for(i=roll_size;i<buffer_size;i++)
  {
  sum-=input[i-roll_size];
  sum+=input[i];
  output[i]=sum/roll_size;
  }

---

Another caveat (vtune & the profilers can help show this): allocating memory is slow -- if you have something like

for(i=;i<1000;i++)
  {
  z=BatchSize(i);
  int *buf = calloc(z * SIZE_OF_ELEMENT);
   ...
  free(buf);
  }

It will work ok for small things, but larger ones will run very slowly because calloc is trying to figure out where to get the memory (ditto for new and delete).