# Reasons for keeping functions small

• 03-25-2006
maththeorylvr
Reasons for keeping functions small
Does the amount of work performed to place a function on the stack change significantly as the size of the function increases? I'm interested in reasons other than appearance and organization, more related to efficiency, that make writing smaller functions a good idea.

Example: A function containing 400 lines of code, 350 of which are contained within conditional statements. Those 350 can obviously be broken down into smaller functions, and would make an improvement, since the work inside one conditional, in this example, is independent of the work inside the others. The only extra overhead would be calling the function within the conditional. How much of a performance gain is there in putting each conditional statement's code in separate functions, if any.
• 03-25-2006
As long as readibility is not affected then there's no need to split up a function like that. If it gets to be 2000 or so lines then it might make sense.
• 03-25-2006
cwr
If you have 350 conditional statements in a function, the data structures and algorthms you're using probably could use some changing.
• 03-25-2006
maththeorylvr
Quote:

Originally Posted by cwr
If you have 350 conditional statements in a function, the data structures and algorthms you're using probably could use some changing.

its not 350 conditional statements, just lines, and this is a hypothetical example, to try and see what you would do in extreme cases. I guess the overhead of allocating a function on the stack isnt that big of a factor in overall performance is it?
• 03-25-2006
xeddiex
Usually you should go by "one job per function". And this is really because it makes the function easier to understand what it's doing at a later time, than say, having n+ jobs. Do not worry about speed, though, it's really irrelevant (especially since C is pretty low level).
• 03-25-2006
maththeorylvr
im doing it in Java, but thought it might be generalizable from C to Java, and languages in general.
• 03-25-2006
WaltP
Quote: