How to write Inline Functions in Python?

[Michael Stenner]

On Fri, Nov 15, 2002 at 11:13:50AM +1100, Delaney, Timothy wrote:
> [python code with timings ommitted]
> 
> The above is a completely different situation - it is a case of inlining
> code directly.

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.

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.

< snipping some C++ stuff >

> In real-world performance, using the 'inline' hint in C++ is usually
> worthless. If you have an optimising compiler, it will tend to ignore your
> hint, and determine for itself what should be inlined (and it's usually a
> better guesser than you are). 

It looks like the current python compiler does not fit this
description.  [ Note: I had a flash of panic as I typed this last
sentence.  I had not used the -O option.  Just tried it, and it made
no difference. ]

> If you *don't* have an optimising compiler, then usually one of two
> things will occur: the compiler will blindly obey all your 'inline'
> hints, usually leading to code bloat and optimisation of things that
> don't need to be,

In that event, the burden falls on the programmer to use inline
responsibly.  You're suggesting that "responsibly" means never.  I
think I can do better than that, especially with profiling.

> or will blindly ignore all your 'inline' hints and will inline
> nothing.

Again, problem with the compiler.

> I've seen lots of code which 'inline'd things all over the place
> ... and then used the STL in performance-critical sections.

And again, problem with the programmer.  Since when does python
withold a useful tool just because it's sometimes abused?

> It comes down to the two rules of optimisation (Knuth? Jackson?):
> 
> 1. Don't do it.
> 2. (For experts only) Don't do it yet.

Those are excellent guidelines.  They're also a bit tongue-in-cheek.
There are times when optimization is useful and beneficial.  You claim
that a good compiler should do it for you.  The python compiler
doesn't.  I understand that improper application of 'inline' can
nastify things, but as it stands, my only real option is to actually
paste the operation in all of the places where it will be used.  This
is MUCH uglier.
					-Michael
-- 
  Michael Stenner                       Office Phone: 919-660-2513
  Duke University, Dept. of Physics       mstenner at phy.duke.edu
  Box 90305, Durham N.C. 27708-0305