CODEWITHSUNDEEP
cperformancedebuggingexpression
Jack
Jack

Reputation: 16724

How to figure performance of small expressions?

I want to figure performance of small expressions,to I decide what to use. Consider the below code. Several recursivee calls to it may happen.

  void foo(void) {
    i++;
    if(etc(ch)) {
    //..
    }
    else if(ch == TOKX) {
        p=1;
        baa();
        c=0;
        p=0;
    }
     //more ifs
}

Question:

Recursives calls may happen to foo(),and i should be incremented only if p has non-zero value(it means that it will be used in other part of code) Should I put a if(p) i++; or only leave i++;?

Is to answer(myself) questions like this that I'm looking for some tool. Someonee can believe that it's "loss of time" or say "optmization is root of evil".. but for cases like this,I don't believe that it is applicable to my situation. IMHO. Tell us your opinion if you think otherwise.

A "ideal" tool,could to show how long time each expression take to run.

It make me to think how is software debugging in biggest software's companies like IBM,Microsoft,Sun etc. Maybe it's theme to another thread.. more useful that this here,I think.

Platform: Should be Linux and MS-Windows.

Upvotes: 0

Views: 77

Answers (2)

Mike Dunlavey
Mike Dunlavey

Reputation: 40649

First please understand which measurements matter: there's total wall-clock time taken by the program, and there's percent of time each statement is active, where "active" means "on the stack".

  • Total wall-clock time is easily measured by subtracting system time after from system time before. If it is very short, just loop the code 1000 times, or whatever. You don't need many digits of precision.

  • Percent of time each statement is active is best measured by means of stack samples taken on wall-clock time (not CPU-only time). Any good profiler based on wall-clock stack sampling will work, such as Zoom or maybe Oprofile. It's not just the taking of samples that's important, but what is presented to you. It is best if it tells you "inclusive percent by line of code", which is simply the percent of stack samples containing the line of code. Again, you don't need many digits of precision, which means you don't need an enormous number of samples.

The reason inclusive percent by line of code is important, as opposed to other measurements (like self-time, function measurements, invocation counts, milliseconds, and so on) is that it represents the fraction of total wall clock time that line is responsible for, and would not be spent if it were not there. If you could get rid of it, that tells you how much time it would save.

Upvotes: 1

canhazbits
canhazbits

Reputation: 1714

The old adage is something like "don't optimize until you're sure, absolutely positive, you need to".. and there are reasons for that.

That said, here are a few thoughts:

  • avoid recursion if you can

  • at a macro level, something like the "time" command in linux can tell you how long your app is running. Put the method in a loop that runs 10k times and measure that, to average out the numbers

  • if you want to measure time spent in individual functions, profiling is what you want. Visual Studio has some good built-in stuff for this in Windows, but there are many, many options.

http://en.wikipedia.org/wiki/List_of_performance_analysis_tools

Upvotes: 2

Related Questions