How to measure code-efficiency?

[Gaijinco]

Every now and then and found two ways to resolve a problem. I try to
find a way to decide which one is best (at least speed-wise) but I
don't know how do I test how long those it take a program to run?

[puzzlecracker]

Gaijinco wrote:

Every now and then and found two ways to resolve a problem. I try to
find a way to decide which one is best (at least speed-wise) but I
don't know how do I test how long those it take a program to run?

I would you a regular timer (one of those that are used during
marathons): start in one hand, while you press enter with a different
one.

Good luck...

tell how it went

[David White]

Gaijinco wrote:

Every now and then and found two ways to resolve a problem. I try to
find a way to decide which one is best (at least speed-wise) but I
don't know how do I test how long those it take a program to run?

I time code execution like this:

#include <ctime>

// ...

clock_t t0 = clock();

// ---- insert code to be timed ----

double tElapsedSec = clock() - t0;
tElapsedSec /= CLOCKS_PER_SEC;

// ...

DW

[Gaijinco]

> #include <ctime>

// ...

clock_t t0 = clock();

// ---- insert code to be timed ----

double tElapsedSec = clock() - t0;
tElapsedSec /= CLOCKS_PER_SEC;

// ...

However, if the time elapsed is really low it shows 0. Is there any way
to measure thousandths of a second?

[Mike Wahler]

"Gaijinco" <ga******@gmail .com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

#include <ctime>

// ...

clock_t t0 = clock();

// ---- insert code to be timed ----

double tElapsedSec = clock() - t0;
tElapsedSec /= CLOCKS_PER_SEC;

// ...

However, if the time elapsed is really low it shows 0. Is there any way
to measure thousandths of a second?

There's no standard portable way. The granularity of
the time used by 'clock()' is implementation defined.
However, most compilers for PCs I've used have
millisecond granularity (i.e. CLOCKS_PER_SEC == 1000).

Another possibility is to use a nonstandard extension
provided by your compiler if it has one. Check your
documentation.

-Mike

[nyoescape]

You can do it indirectly, by repeating it again and again for a
specified time:

clock_t t0 = clock();
unsigned long n = 0;

while ( float(clock()-t0)/CLOCKS_PER_SEC < 1) {
// code here will repeat itself for a second
++n;
}

double elapsed = (float(clock()-t0)/CLOCKS_PER_SEC)/n;

That's what I usually do - it gets more accurate the longer you repeat
the code.

[nyoescape]

Oops, should've use double() instead of float() there. Sorry.

[kamit]

how about using gettimeofday?

[Mike Wahler]

"kamit" <kh************ *@gmail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

how about using gettimeofday?

No such function in standard C++.

Also, 'time of day' functions, standard or not,
typically don't have as low a granularity as
'clock()'.

-Mike

[mlimber]

Gaijinco wrote:

Every now and then and found two ways to resolve a problem. I try to
find a way to decide which one is best (at least speed-wise) but I
don't know how do I test how long those it take a program to run?

Several points:

* Generally speaking, given two pieces of code that solve the same
problem, you should keep the one that is the most portable,
maintainable, and extensible. Speed should not be a primary
consideration unless the piece of code is a *known* bottleneck (see the
next two points).

* You can use a profiler to calculate how long a particular piece of
code takes to run, and more importantly, you use a profiler to find out
if that piece of code is a bottleneck. There is no sense in optimizing
(or recoding in assembler or whatever) when a working, unoptimized
piece of code meets the requirements. Check your platform or
development documentation for more information on profiling on your
system.

* Beware Premature Optimization (from
http://gotw.ca/publications/mill09.htm):

'If you're a regular reader of this column, you'll already be familiar
with my regular harangues against premature optimization. The rules
boil down to: "1. Don't optimize early. 2. Don't optimize until you
know that it's needed. 3. Even then, don't optimize until you know what
needed, and where."

'By and large, programmers--that includes you and me--are notoriously
bad at guessing the actual space/time performance bottlenecks in their
own code. If you don't have performance profiles or other empirical
evidence to guide you, you can easily spend days optimizing something
that doesn't need optimizing and that won't measurably affect runtime
space or time performance. What's even worse, however, is that when you
don't understand what needs optimizing you may actually end up
pessimizing (degrading your program) by of saving a small cost while
unintentionally incurring a large cost. Once you've run performance
profiles and other tests, and you actually know that a particular
optimization will help you in your particular situation, then it's the
right time to optimize.'

Cheers! --M