By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,617 Members | 1,896 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,617 IT Pros & Developers. It's quick & easy.

Making a program quicker tips...

P: n/a
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?

What are some tips to make a program quicker?

TIA,
cmad
Jul 22 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Chris Mantoulidis wrote:
What are some tips to make a program quicker?


Use a faster algorithm. This can produce x% speed increase, where x is
any number. I have for example gained speed increase from 15 minutes to
100ms by just selecting another algorithm instead of the old one, to do
the very same thing the old did.

I also managed to drop 90ms more execution time by not doing things in
my code. For example I first reseted all values in my array to zero in
the beginning of a loop. Then I noticed that I can just insert the
values into my array, and set the first value after real values to zero,
and get the same result, but in much shorter time.

Usually it helps to find what is making it slow. Search for the slow
part in your code, usually it is a loop, and then think how to make it
faster. It isn't usually smart to optimise all of the code, because that
decreases the readability and wastes your time.
Jul 22 '05 #2

P: n/a
"Chris Mantoulidis" <cm****@yahoo.com> wrote...
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?

What are some tips to make a program quicker?


First tip: don't do it, unless you have to.

Second tip: to know whether you have to or not, make sure
you have some kind of performance requirement expressed in
understandable terms, like "the program has to do fifteen
summersaults in a millisecond".

Third tip: if you do have your requirements and are ready
to undertake "performance improvements" of your program,
make sure you have the necessary tools - something to time
your program's execution and especially something to find
the performance bottlenecks, usually these are combined in
a tool called "profiler".

Fourth tip: of course, there is no real sense to write your
program slow the first time around, so using decent algos
is essential, therefore, you need to study algorithms to
know which ones are faster in what situations. Of course,
after the program is written, see Third tip.

Fifth tip: know when to stop tweaking your program. You
can strive for perfection, but usually perfection is out
of our reach. You can only do so much during a normal
lifetime, don't waste it all on illusive performance
improvements.

I am not sure what your C++ language question was. Perhaps
next time you could be a bit more on topic.

Victor
Jul 22 '05 #3

P: n/a
Chris Mantoulidis wrote:
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?

What are some tips to make a program quicker?

TIA,
cmad


As others have said:
1. Don't optimize unless absolutely necessary.
2. Choose more efficient algorithms.
3. Remove unnecessary code, data and requirements.
4. Choose more efficient data structures.
5. Don't copy large blocks of data; use pointers.

As far as the "if" statements go, don't worry about them.
You could combine some if statements and use short-circuiting
with the logical operators. Apply Boolean Algebra to your
if statements to reduce them down. However, always
strive for readability in your programs.

The only advantage to removing "if" statements is
to provide continuous execution and reduce reloading
of an instruction cache. Some processors have an
instruction cache. These caches get reloaded when
branch instructions are processed. Reloading the
cache is an expensive proposition. However, the
speed gain is negligible in most circumstances.
Only programs that have real-time requirements or
large data processing should be concerned about
this issue. For the most part, waiting for a
piece of hardware or user input will absorb any
gain from cache optimization. It's kind of like
driving fast to reach a stop sign or traffic
signal.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Jul 22 '05 #4

P: n/a
> First tip: don't do it, unless you have to.

I have to :(
Second tip: to know whether you have to or not, make sure
you have some kind of performance requirement expressed in
understandable terms, like "the program has to do fifteen
summersaults in a millisecond".
I got that kinda instructions
Third tip: if you do have your requirements and are ready
to undertake "performance improvements" of your program,
make sure you have the necessary tools - something to time
your program's execution and especially something to find
the performance bottlenecks, usually these are combined in
a tool called "profiler".

Fourth tip: of course, there is no real sense to write your
program slow the first time around, so using decent algos
is essential, therefore, you need to study algorithms to
know which ones are faster in what situations. Of course,
after the program is written, see Third tip.

Fifth tip: know when to stop tweaking your program. You
can strive for perfection, but usually perfection is out
of our reach. You can only do so much during a normal
lifetime, don't waste it all on illusive performance
improvements.

I am not sure what your C++ language question was. Perhaps
next time you could be a bit more on topic.
No I was wondering if in some way I could use something else instead
of (for example) "for" in my C++ code to make the prog faster. But it
seems like it's mostly an algorithm issue.

Thanks all,
cmad
Victor

Jul 22 '05 #5

P: n/a
"Chris Mantoulidis" <cm****@yahoo.com> wrote in message
news:a8**************************@posting.google.c om...

I am not sure what your C++ language question was. Perhaps
next time you could be a bit more on topic.
No I was wondering if in some way I could use something else instead
of (for example) "for" in my C++ code to make the prog faster.


The only way to find out is to measure. And note that this measurement
could easily change if you use different compiler options, a different
compiler, a different version of the same compiler, a different platform,
etc, etc.
But it
seems like it's mostly an algorithm issue.


It typically is.

And re your remark in your original post about using 'if':
Anybody who tells you that an 'if' statement is instrinsically
'slow' shouldn't be giving out advice about optimization.
-Mike
Jul 22 '05 #6

P: n/a
Chris Mantoulidis wrote:

What are some tips to make a program quicker?


First, use a profiler (e.g. gprof) to find the critical
piece of code. Sometimes it is not what you expect.

I once had the problem that some code was awfully slow. I
tuned the algorithm to now avail. It became only a bit faster.

After some profiling I found out that the progress bar
control(!) I used needed alot of time. Commenting it out
made the program run 6 times faster(!).

I would never have expected that this %#&*!$ control was
the source of the problem.

So, to say it again: Use a profiler!!

Then, when you found it, try to improve it. Maybe post the
critical code segment and the problem you want to solve. And
mention that you already used a profiler, else a lot of
people will ask you why you want to optimize it.

hth

Christoph

hth

Christoph
Jul 22 '05 #7

P: n/a
"Chris Mantoulidis" <cm****@yahoo.com> wrote in message
news:a8**************************@posting.google.c om...
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?


The conventional wisdon that you should be careful not to optimize
prematurely, and that you should use a profiler, is correct. However,
if you want to write code which will be amenable to optimization
later, you should have some rough idea about how expensive various
language constructs are, for instance dynamic allocation, use of RTTI,
thread syncronization (although this is not standard) and operations
which generate temporary objects. You can get this from, e.g.,
Meyers's More Effective C++.

Jonathan
Jul 22 '05 #8

P: n/a
cm****@yahoo.com (Chris Mantoulidis) wrote in message news:<a8**************************@posting.google. com>...
First tip: don't do it, unless you have to.


I have to :(


I'm pretty sure he meant "don't make your code do something
unless you have to." In other words, don't do stuff you don't
need to do.

The first two rules of optimisation.
1) Don't do it until you have to.
2) Don't do it.

There are ways to trade speed for space, for example. But they
are plenty of work, and don't *always* increase speed. Just as
an example, think about a loop to fill memory. You could fill
it byte-by-byte. However, you could fill a multi-byte variable,
then fill memory with that multi-byte value. But then you have
just tons of caveats and gotchas. For example, portability can
be an issue if different platforms have different word size.
And on some platforms, writing a word and writing a byte may
not be related by the naive ratio of two you might expect. And,
of course, you have the issue of "uneven" parts at the end if,
just for example, you use a two byte variable to fill an odd
number of bytes.

There are many other possibilities, but they depend pretty
strongly on the details of your application and platform.
You might get better help if you asked in a news group that
specializes in your platform, and gave some specifics of the
application you are dealing with.
Socks
Jul 22 '05 #9

P: n/a
In article <a8**************************@posting.google.com >,
Chris Mantoulidis <cm****@yahoo.com> wrote:
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?


If avoiding "ifs" is your only alternative then you are doomed
and you should convert your code to assembly and kiss maintainability
goodbye.

A friend of mine told me a story about optimizing code. He was
writing a compression algorithm for his company (there weren't
any libraries available that he could use - this was a while ago)
and he quickly whipped up a version in C that did that job. Another
guy at the company converted it to assembly language and made it
twice as fast. My friend, after some thought, rewrote part of his
code to use a better search algorithm and made his code twice as
fast as the assembly language version. Assembler guy converts that
new code to assembly language and produces a version about 1.5 times
faster. Realizing that this was war, my friend spent a late night
testing and rejecting alternatives, shouting at the heavens, and
reading the holy books of computer science, and finally produced a
version that was between 10 and 20 times faster than the previous
fastest version and could compress significantly faster than it could
read the data from the disk. Assembler guy was smart enough to admit
defeat (he later converted the code to assembly language and squeezed
about 10% out of it, and even *he* wasn't that impressed).

The moral of the story: Choose good algorithms and write them well.

Know your tools and use them well.

Know your hardware and use it well.

Don't optimize until you know you need to.

Don't pessimize unless circumstances leave you no choice.

Alan
--
Defendit numerus
Jul 22 '05 #10

P: n/a

"Alan Morgan" <am*****@Xenon.Stanford.EDU> wrote in message
news:c0**********@Xenon.Stanford.EDU...
In article <a8**************************@posting.google.com >,
Chris Mantoulidis <cm****@yahoo.com> wrote:
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?


If avoiding "ifs" is your only alternative then you are doomed
and you should convert your code to assembly and kiss maintainability
goodbye.


Although it might not look like it, you'd still be using
an 'if' mechanism, albeit expressed by a 'compare' followed
by a (conditional, inherent in the instruction), jump.

-Mike
Jul 22 '05 #11

P: n/a
Chris Mantoulidis wrote:
There must be some tips to make a program quicker.

I guess more than 50% of ppl here will say "avoid the if-s". Yeah I
know this makes a program quicker but some times an "if" is
inevitable, isn't it?

What are some tips to make a program quicker?

TIA,
cmad

First - find your hotspots by using a profiler (valgrind etc.).
Next - check if you could use a better algorithm there. Then check if you
copy big objects (like strings!) unnecessarily. Change a
A::method(string ahalfbook)
to
A::method(const string &ahalfbook)
and so on. If you call small methods often inline them. Other tips:

1. Use compile-time linkage if applyable:
Not
class A{
public:
A(FilterBase *filter,int N) { myfilter=filter;
myfilter->setBlockSize(N);}
~A()
void transform(float *x, int size) { myfilter->apply(x,size); }
protected:
FilterBase *filter;
};
But
template<class T,template<class> class Filter> A{
A(int N) : MyFilter(N) {}
~A() {}
void transform(float x, size_t size) { assert(size==MyFilter.BlockSize());
MyFilter.transform(x);
protected:
Filter MyFilter;
};
this example also shows how to initiate objects with constructor arguments
without using new or .resize()-methods.

2. Use valarrays or Blitz++-Arrays for numerical stuff. Valarrays are faster
than C arrays since the compiler can assume the absence of aliases and thus
use aggressive optimizations.

3. For the same reason prefer index access to C arrays over pointer
arithmetics. If there is a pointer to an array the compiler cannot be sure
that you use a pointer-to-that pointer for accessing the array. If you do
that it (the compiler) cannot hold the values in registers nor the cache.

4. Avoid floating-point divisions. This
float b,c;
float a=b/c;
float e=a/c;
take much more time than that
float b,c;
float tmp=1.0/c;
float a=b*tmp;
float e=a*tmp;

5. prefer float to double since float's could be used in SIMD instructions
(SSE,3Dnow).

6. prefer signed ints over unsigned ints when performing
int-to-float-conversions.

7. Prevent type conversions where you can!

8. Move all stuff out of loops what you can get out.

9. Use unsigned int datatypes for loop counters.

10. Make usage of the superscalable cores / SIMD instructions; transform
for(size_t i=0;i<100;i++) sum += data[i];
into
float sum1,sum2,sum3,sum4;
sum1=sum2=sum3=sum4=0.0;
for(size_t i=0;i<100;i+=4)
{
sum1 += data[i];
sum2 += data[i+1];
sum3 += data[i+2];
sum4 += data[i+3];
}
float sum = sum1 + sum2 + sum3 + sum4;

11. Use a decent compiler with aggressive optimization flags (e.g. g++ >
3.2)

Jul 22 '05 #12

P: n/a
5. Don't copy large blocks of data; use pointers.

You meant: use const-refs or refs - didn't you?
A::method(const string &message) { ... }

Jul 22 '05 #13

P: n/a
Ruediger Knoerig wrote:
5. Don't copy large blocks of data; use pointers.


You meant: use const-refs or refs - didn't you?
A::method(const string &message) { ... }


Actually, I meant pointers. This is from the C
point of view. References could also be used.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Jul 22 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.