Thread: A big function or not?

  1. #1
    Registered User
    Join Date
    Feb 2008
    Posts
    147

    A big function or not?

    I have a program which has a very large function (plus many others), basically it does a long loop inside that function.
    will splitting the function in smallers ones improve the overall performance? is doing things in small parts usually a good thing for speed or no? I know it depend on the program, but I am asking for the general rule.
    I am thinking that splitting the function will generate a overload to the call stack.
    ( I will test it, but I need lot of time to rewrite all and would like hear your opinions before).
    Thanks

  2. #2
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,834
    No performance increase. However it is usually better for human comprehension.
    If you are worried about stack then yes, perhaps there are too many local variables which could be compartmentalized into smaller functions. Of course if you call function A, which calls function B calling function C, then all the stacked values eat up the same amount of total stack. But if A calls B. Finishes, then calls C, stack use is less.

    In a situation where everything is in a long loop, and you introduce function calls, there is a slight performance hit because calling functions take time vs. in-line code. Assuming the compiler doesn't do some cleaver optimizing.

  3. #3
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    ...doesn't do some cleaver optimizing.
    You can't beat that "cleaver optimizing", for sure!

  4. #4
    Registered User
    Join Date
    Sep 2007
    Posts
    1,012
    If your compiler is good, then it may actually improve performance if you split a large function up into smaller ones. This way the compiler can choose either to inline a function or call it, at its discretion. The advantage here is that (hopefully) the compiler knows which one will provide better performance.

    But in truth, unless you know there's a performance problem, don't worry about it. If you do know there's a problem, profile before assuming you know where the source of the problem is. Generally speaking, you want to pick good algorithms and then write them in the most natural way possible, without worrying about microoptimization. That's the compiler's job.

  5. #5
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    It probably wont directly affect performance, but by splitting large things up, you can see more clearly the kinds of things that you could optimise anyway.

    It wont result in stack overflow as the functions you break it up into wont be calling one another recursively.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #6
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Kempelen View Post
    I have a program which has a very large function
    Define "very large function"....

    My personal record is ~450 lines that just didn't lend themselves well to being split up... Opened a midi file, translated it and imported the events into an array of structs... all in one pass.

    100+ line functions are not at all uncommon when working on a single unified sequence of events.

    I don't think there's a huge gain to be made by splitting things up... Especially not if you're looking at a month of development time to save a few milliseconds execution time.
    Last edited by CommonTater; 03-18-2011 at 07:21 PM.

  7. #7
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by CommonTater View Post
    My personal record is
    OP, don't pay any attention to him. Everything with this dude is a contest. He loses them all, but still, everything's a contest.


    Quzah.
    Hope is the first step on the road to disappointment.

  8. #8
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by quzah View Post
    OP, don't pay any attention to him. Everything with this dude is a contest. He loses them all, but still, everything's a contest.


    Quzah.
    Oh yeah, that's an adult way to behave.

  9. #9
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Okay so apparently you two don't get along.
    No need to pollute the thread with anything uncivilised though.


    Breaking a function up into smaller functions does not take too long, or more accurately, it only takes as long as you want to spend doing it. The fact that you're even asking on here says that you recognise already that it is too large and you just need a little push to break it up somewhat. You'll probably be glad you did. So here goes:
    *nudge* *nudge*

    Really liking these forum upgrades eh!
    Last edited by iMalc; 03-18-2011 at 10:32 PM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Sudoku Brute Force Algorithm Help (recursion?)
    By ridilla in forum C Programming
    Replies: 22
    Last Post: 05-07-2010, 03:31 PM
  2. doubt in c parser coding
    By akshara.sinha in forum C Programming
    Replies: 4
    Last Post: 12-23-2007, 01:49 PM
  3. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  4. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 01:03 PM
  5. Replies: 5
    Last Post: 02-08-2003, 07:42 PM

Tags for this Thread