How to write Inline Functions in Python?

Delaney, Timothy tdelaney at avaya.com
Sun Nov 17 18:37:04 EST 2002


> I understand that this thread has gone in a couple of different
> directions.  Just to be clear, I'm talking about python and addressing
> your assertion that modern compilers/computers obsolete the necessity
> for programmer-requested inline functions.  I am talking about
> 'inline'ing code solely for the purpose of speed; avoiding the
> function call/stack overhead for small operations.

Yes - but this is a completely separate issue. The question asked was about
"inline functions". Inlining code is not an *inline function*.

Python has no concept of *inline functions*.

> The example I gave was the first one that occured to me, and not at
> all dissimilar from things I've done in the past.  If the python
> compiler was supposed to inline that (being a modern compiler and all)
> then it failed.  I wouldn't mind if I could do "inline def(...):", but
> I can't.

The python compiler does absolutely no optimisations unless you use -O, and
even that is simply removing cruft that is *added* to aid developers. And
the difference is going away almost completely in 2.3.

This boils down to "if you are worried about the performance of your
program, then Python may not be the right language for you".

There are of course *idiomatic* optimisations in Python - and explicitly
inlining code because you know the performance characteristics of Python
name lookups and function calls is one. However, it is even more idiomatic
not to worry about such performance characteristics until they prove to be a
problem.

But none of this has anything to do with *inline functions* which is what
the original poster asked about. A language which (supposedly) gets so close
to the metal as to expose the implementation details of the code produced
(such as via an "inline" hint) *should* these days have highly-optimising
compilers. If your compiler does not have such optimisations, then the
"inline" hint is probably useless. If it *does* have such optimisations,
then the "inline" hint is also probably useless.

Humans have been shown time and again to be exceptionally bad guessers as to
what needs optimising. As such, humans should concentrate on making their
code as clear and readable as possible, and let the automated systems (such
as a compiler) work out what is the best optimisation.

And yes, I have produced *highly* optimised code in Python (two orders of
magnitude improvement in performance over the naive implementation). In each
case, the majority of the performance improvement was by improved algorithms
(most importantly, only doing things when you absolutely have to). Using
optimisation "tricks" (inlining code, using default parameters for function
names to avoid global lookups, etc) have only been used in one particular
project (a coverage tool) where absolute best possible performance is a
requirement (and the final result is an overall increase in runtimes when
run under the coverage tool of around 50%).

Tim Delaney




More information about the Python-list mailing list