Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Time A Script 1

Status
Not open for further replies.

TamedTech

IS-IT--Management
May 3, 2005
998
GB
Hello Guys,

I've got two scripts that i've written for performing the same task, and i'm looking to compare the performance of them both.

Can I time the performance of a script? and have it output the time after completion of its tasks?

Thanks,

Rob
 
Yes you can, but details vary from one platform to another. What is your setup?

Also, C source files are programs, not scripts.



--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
 
Hello Salem,

Sorry about the 'scripts' referance bud, I'm a Web application architech during the day, I only become a C programmer by night :-D.

I dont really know what details to give about my setup. I'm writing c programs using the Eclipse SDK, then transfering to my linux box and compiling with GCC. Does that help at all?

Basicly the proceeduire i'm testing is a single function within the program, i just want to test the time it takes from the first command in the function to the last.

Rob
 
You can get a pretty crude idea with something like this
Code:
#include <stdio.h>
#include <time.h>

void baz ( void ) {
    volatile int i;
    for(i=0;i<10000000;i++);/* work */
}

int main ( int argc, char *argv[] ) {
    clock_t t1, t2;
    t1 = clock();
    baz();
    t2 = clock();
    printf("%f\n", ((double)t2 - t1)/CLOCKS_PER_SEC );
    return 0;
}
but the amount of work you need to do before the clock registers a difference can run into milliseconds (or worse).

If the function can be called multiple times without adverse side effects, then you can get better accuracy with say
Code:
    t1 = clock();
    for ( i = 0 ; i < 100 ; i++ ) baz();
    t2 = clock();
    printf("%f\n", ((double)t2 - t1)/CLOCKS_PER_SEC/100 );

--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
 
Salem, I see in your first example you used the volatile keyword. I've never had a need to use it, but I always thought it was only needed for multi-threaded programs or shared memory or something? Does 'i' really need to be volatile there, and if so why?
 
Well if you don't make it volatile, any half-decent compiler will notice that the loop does nothing, and just remove it from the generated code - the result being the loop takes no time at all to run, no matter how large you make it.


--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
 
Really? That's strange. You'd think if the compiler was smart enough to know the loop does nothing that it would remove it whether the int was volatile or not?
Maybe a better compiler should just issue a warning just like it does for "code unreachable" or "unused local variable"...
 
Thank you guys, that really has been a great help,

I'll give this a proper run through this afternoon.

Thanks again,

Rob
 
draft c99 said:
A volatile declaration may be used to describe an object corresponding to a memory-mapped
input/output port or an object accessed by an asynchronously interrupting function. Actions on
objects so declared shall not be ‘‘optimized out’’ by an implementation or reordered except as
permitted by the rules for evaluating expressions.
In short, if you have
Code:
volatile int a;
a = 2;
a = 3;
Then both assignments will appear in the executable, independent of the level of optimisation.

The fact that it seems like a local variable with no obvious means of any external entity having visibility of the variable doesn't change that.

This would be vitally important say if 'a' were a device register (say a serial port), and you were trying to write a string to it one character at a time. You'd be rightly annoyed if the compiler decided that the net effect was to just write the last character.


--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
 
I guess it's good to have a little insurance built in, just incase a compiler thinks it's smarter than it really is... ;-)
Now I may finally have a use for the volatile keyword.
Thanks.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top