1

Possible Duplicate:
Does creating separate functions instead of one big one slow processing time?

OOP Bloop boop!

Yes, OOP is great, keeps code clean and well organized. That's why I like to use it. I"m referring to to OOP very primitively specifically in using functions (defs).

Will taking out my function calls and sticking the content of the function straight into my algo increase speed of execution of the overall code? Yes, I know I can run a test myself, but I'm choosing to ask it here in the forum of my fellow coder colleagues, because I know this is a question that floats around in many heads....

def myFunc(var):
   return var*3243 #perhaps more complicated function code will make a difference?

i = 0
hungry = True
while hungry:
  i = i + 1
  x = myFunc(i)
  if i > 50:
     hungry = False
Community
  • 1
  • 1
drinkice
  • 11
  • 1
  • 1
    Assume the compiler is smarter than you are. – Greg Hewgill May 04 '11 at 01:31
  • 1
    "Yes, I know I can run a test myself". Please, please, please. Run the test yourself first so we know what you're *actually* talking about. We can assume a lot of random things, we don't know what *you* are assuming. – S.Lott May 04 '11 at 01:35
  • 1
    You introduce your question with OOP concept but your question have nothing to do with OOP. Or if its the case you should clarify this. – Lynch May 04 '11 at 01:36
  • 2
    @Felix Kling: The interesting thing is that the answer in that question appears to be at least partially incorrect. – Swiss May 04 '11 at 01:40
  • The question isn't about a specific piece of code, but about general behavior of function calls vs. code speed, it can apply to any situation where speed execution is very important. The ambiguity is purposeful to make the question more open and the answers more useful to everyone who seeks them. – drinkice May 04 '11 at 01:42
  • 2
    @drinkice: "The ambiguity is purposeful" but also makes the question just a pointless rehash of potential trade-offs and would-have, could-have, may-have and usually. Please provide *something* concrete so that there's a remote possibility of an actual, factual answer. – S.Lott May 04 '11 at 01:45
  • 2
    @Greg Why? The compiler can't assume anything. Given the information it has, it's often not allowed to modify very much in order to increase performance. Especially in languages as dynamic as Python. Some completely different module could potentially import this module and then alter myFunc as the program is running. Given our background knowledge, that's not going to happen. But the compiler doesn't have that knowledge. Clearly, we *are* smarter than the compiler. – Ponkadoodle May 04 '11 at 01:49

3 Answers3

3

Write it correctly (i.e. with concerns properly separated into distinct functions and classes), then use PyPy to make it fast.

PyPy uses function inlining and assorted other tricks in its Just-In-Time compiler to speed up code execution without having to make it unmaintainable in the name of speed.

Note that this solution only works if you're using the Python 2.x series with any C extensions you use being compatible with cpyext.

ncoghlan
  • 40,168
  • 10
  • 71
  • 80
2

Apparently there is very high function call overhead in Python.

http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Data_Aggregation

Is it worth keeping in mind while choosing the best way to write a piece of code?
Sure.
Is the speed up worth making your coder harder to understand?
Probably not.

Swiss
  • 5,556
  • 1
  • 28
  • 42
  • I just had a revolutionary idea... For most simple situations, I'm just using functions to simply make the code easier to read, especially functions which contain large chunks of code. If using OOP and function calls is purely to satisfy a better visual appearance, this should be the job of the IDE or visual code editor you are using and not by changing the way your code operates (using OOP, functions, etc..) – drinkice May 04 '11 at 02:18
  • ie: someone should make a procedural friendly code editor that lets you minimize chunks of code (not necessarily those under brackets or indents), slap a name to identify what this chunk of code does, and then minimize it, thus satisfying an organizational need and making the code easier to read (thus easier to debug, edit, etc.. --> which is usually the strongest argument for OOP anyways...) – drinkice May 04 '11 at 02:18
  • this way you won't have to OOP-asize your code (sacrificing speed) to gain better visual appearance, code has enough responsibility already (functionality), we don't need to add the job of good visual appearance to our "instruction set" (code), and manipulate it permanently, this is a task for our visual editing tools – drinkice May 04 '11 at 02:20
  • I guess this is what a compiler ultimately does, although we can see that it doesn't always do it as well as we'd specifically like (no inlining functions in python...?) – drinkice May 04 '11 at 02:24
  • @drinkice: "I guess this is what a compiler ultimately does," Correct. Nothing revolutionary about it. If you want this functionality, stop using Python and use C++, Java or C# or similar. – S.Lott May 04 '11 at 03:34
0

Python won't "inline" the function for you, so of course there is overhead. Usually the code in the function will take enough time that the call overhead is not significant.

Bear in mind that it's much easier to test,debug and profile programs that are broken up into functions.

If you really really need more performance it's usually a better idea to write the function in C or Cython than to eliminate the call overhead

It's also worth noting that the usual code set up like this

def main():
   ...

if __name__=="main":
    main()

is faster than just running code at the top level as identifier lookups are faster in functions/methods than in the global namespace

John La Rooy
  • 295,403
  • 53
  • 369
  • 502