Functioning In C

Discussion in 'C Programming' started by Abhishek, Oct 6, 2003.

  1. Abhishek

    Abhishek Guest

    How Does Functioning(Breaking in seperate block according to the logic
    using functions) a Programme effect the performance of the programme
    Abhishek, Oct 6, 2003
    #1
    1. Advertising

  2. Abhishek

    Mike Wahler Guest

    "Abhishek" <> wrote in message
    news:...
    > How Does Functioning(Breaking in seperate block according to the logic
    > using functions) a Programme effect the performance of the programme


    Negligibly. Drastically. Not at all. Context, context, context.

    The organization of program logic into functions will
    indeed greatly affect programmer productivity.


    -Mike
    Mike Wahler, Oct 6, 2003
    #2
    1. Advertising

  3. On Mon, 6 Oct 2003, Abhishek wrote:

    > How Does Functioning(Breaking in seperate block according to the logic
    > using functions) a Programme effect the performance of the programme


    The generic answer is... it depends. It is almost guaranteed that there
    will be some overhead involved with functions. This means there will be
    some deduction of performance. I say ALMOST guaranteed because it is never
    100% guaranteed.

    On some compilers everything might become linear assembly. From a source
    code view there are a lot of functions and branching. From the machine
    language view everything is linear as if the program was written as one
    big function called main().

    In other circumstances, a function call could be translated to a branch
    instruction. On processors with caching and pipelines, a branch is very
    costly. Breaking a program into many small functions could double or
    triple the running time of the program.

    Bottom line, it depends on many factors. All of these factors are outside
    the domain of comp.lang.c. What you are looking for is more in line with
    specific implementations of C language. Tere should be newsgroups to help
    you out if you focus on your operating system and compiler.

    --
    Send e-mail to: darrell at cs dot toronto dot edu
    Don't send e-mail to
    Darrell Grainger, Oct 6, 2003
    #3
  4. Abhishek

    osmium Guest

    Abhishek writes:

    > How Does Functioning(Breaking in seperate block according to the logic
    > using functions) a Programme effect the performance of the programme


    A copy of each argument must be moved to the "stack". The processor
    probably has something like 'call' and 'return' as instructions designed
    especially with the intent of there *being* a stack. And one of each of
    those must be executed. The space for the stack must be managed which might
    possibly be a single add or subtract instruction. The result, if any,
    probably has to be moved someplace special. I'm thinking something of the
    order of a half-dozen instructions plus one instruction per parameter.

    Naturally, all of this depends on the microprocessor used and the compiler
    design. The short answer is that I would not avoid using functions because
    of the overhead. If you are at the point where this is a potential problem
    you should probably consider switching to assembly language. The compilers
    I am familiar with are not really as good at "doing" registers and getting
    all the good out of them as the human mind is.
    osmium, Oct 6, 2003
    #4
  5. (Abhishek) wrote in message news:<>...
    > How Does Functioning(Breaking in seperate block according to the logic
    > using functions) a Programme effect the performance of the programme


    You really shouldn't worry about this too much unless you have to.

    And you probably don't have to.

    What you should worry about is how easy the program is to read,
    understand, maintain, and change. Seperating it into functions greatly
    helps that process. Seperating it into functions helps you break the
    problem down into managable chunks, which can be easily solved one at
    a time. Once all of the small problems have been solved, your big
    problem has also been solved.

    Finally, breaking down the problem also breaks down the solution. All
    of those small solutions can be used again in a different program.
    Code reuse is a great thing, and generating functions instead of just
    writing one big main() is a simple, obvious means to that end.
    August Derleth, Oct 6, 2003
    #5
  6. Abhishek

    cody Guest

    > How Does Functioning(Breaking in seperate block according to the logic
    > using functions) a Programme effect the performance of the programme


    if the function is rather big there is no real performance loss. if you
    really care about speed use a macro.

    --
    cody

    [Freeware, Games and Humor]
    www.deutronium.de.vu || www.deutronium.tk
    cody, Oct 10, 2003
    #6
  7. Abhishek

    Mike Wahler Guest

    "cody" <> wrote in message
    news:bm4sdc$imosl$-berlin.de...
    > > How Does Functioning(Breaking in seperate block according to the logic
    > > using functions) a Programme effect the performance of the programme

    >
    > if the function is rather big there is no real performance loss.


    What are your premises for this statement?

    > if you
    > really care about speed use a macro.


    What are your premises for this statement?

    -Mike
    Mike Wahler, Oct 10, 2003
    #7
  8. Abhishek

    NumLockOff Guest

    "Mike Wahler" <> wrote in message
    news:a0phb.3948$...
    > "cody" <> wrote in message
    > news:bm4sdc$imosl$-berlin.de...
    > > > How Does Functioning(Breaking in seperate block according to the logic
    > > > using functions) a Programme effect the performance of the programme

    > >
    > > if the function is rather big there is no real performance loss.

    >
    > What are your premises for this statement?
    >
    > > if you
    > > really care about speed use a macro.

    >
    > What are your premises for this statement?
    >
    > -Mike
    >
    >


    What I gather from Cody's response is that
    if the function is really small make a macro out of it to save the jumps and
    push/pop registers.

    If you have a silly func

    SetTo12(int *px)
    {
    *px =12;
    }


    it is better to have the macro
    #define SET_TO_12 (iii) iii=12

    ....

    Well this example is too silly, but i hope you get the point..
    NumLockOff, Oct 10, 2003
    #8
  9. On Thu, 9 Oct 2003, NumLockOff wrote:

    > What I gather from Cody's response is that
    > if the function is really small make a macro out of it to save the jumps and
    > push/pop registers.


    If that were the only advantage there would be little point in inlining.
    The real speedup comes from that the compiler can perform a whole flock
    of other optimizations when it integrates the piece of code in an
    expression.

    Consider e.g.

    #define cat1(x) ((x)*2+1)
    #define cat0(x) ((x)*2)
    unsigned foo(unsigned x) {
    return cat0(cat1(cat0(cat1(cat0(cat1(x))))));
    }

    This is optimizable to x*64+42. (Though whether it actually happens
    is a different matter..)
    Jarno A Wuolijoki, Oct 10, 2003
    #9
  10. Abhishek

    Mike Wahler Guest

    "NumLockOff" <> wrote in message
    news:p...
    >
    > "Mike Wahler" <> wrote in message
    > news:a0phb.3948$...
    > > "cody" <> wrote in message
    > > news:bm4sdc$imosl$-berlin.de...
    > > > > How Does Functioning(Breaking in seperate block according to the

    logic
    > > > > using functions) a Programme effect the performance of the

    programme
    > > >
    > > > if the function is rather big there is no real performance loss.

    > >
    > > What are your premises for this statement?
    > >
    > > > if you
    > > > really care about speed use a macro.

    > >
    > > What are your premises for this statement?
    > >
    > > -Mike
    > >
    > >

    >
    > What I gather from Cody's response is that
    > if the function is really small make a macro out of it to save the jumps

    and
    > push/pop registers.


    What "push/pop registers?" This is ISO C, remember.

    > If you have a silly func
    >
    > SetTo12(int *px)
    > {
    > *px =12;
    > }
    >
    >
    > it is better to have the macro
    > #define SET_TO_12 (iii) iii=12


    I almost always prefer a function over a macro,
    especially when side effects are involved. I try
    to always only use macros to express "magic numbers."

    > Well this example is too silly, but i hope you get the point..


    I understand your point, but disagree with it, as
    well as Cody's assertion that a macro will necessarily
    give better performance than a macro.

    The *only* way to accurately determine if one method
    performs faster than another is to measure.

    -Mike
    Mike Wahler, Oct 10, 2003
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sadf
    Replies:
    4
    Views:
    803
    Bob Carsto
    Nov 14, 2003
  2. =?Utf-8?B?bG91aXNlIHJhaXNiZWNr?=

    Enable property of a Panel not functioning

    =?Utf-8?B?bG91aXNlIHJhaXNiZWNr?=, Feb 7, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    347
    =?Utf-8?B?bG91aXNlIHJhaXNiZWNr?=
    Feb 7, 2005
  3. surveyor04
    Replies:
    0
    Views:
    366
    surveyor04
    Feb 12, 2005
  4. Neo Geshel
    Replies:
    5
    Views:
    838
    =?Utf-8?B?UHJha2FzaC5ORVQ=?=
    Jun 14, 2005
  5. =?Utf-8?B?Q2hyeXNhbg==?=

    Comboxbox's SelectedIndexChanged event not functioning

    =?Utf-8?B?Q2hyeXNhbg==?=, Sep 29, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    422
    =?Utf-8?B?Q2hyeXNhbg==?=
    Sep 29, 2005
Loading...

Share This Page