How to write Inline Functions in Python?

[Michael Stenner]

On Mon, Nov 18, 2002 at 10:37:04AM +1100, Delaney, Timothy wrote:
> > 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*.

There's a chance I'm misunderstanding something here.  An "inline
function" is a function you've written and asked the compiler to treat
as "inline code", right?  In many ways, it's like a glorified macro.
If I"m wrong please correct me.

> Python has no concept of *inline functions*.

Yes.  I understand that.  That is precisely the fact that I'm discussing.

> > 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.

And yet when you explained to the OP why 'inline' was unnecessary, the
reason you gave was that modern compilers to a better job at
optimization than humans (usually).

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

That's a fair point.  Serious speed is not python's goal, and that's
fine.

> 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.

Yes, and when they prove to be a problem, you optimize.

> 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.

I feel like we're going around in circles here.  I'm talking about
python.  It looks like 'inline' would produce serious speedups in some
cases.  Therefore, it looks like an inline command would not be
useless.

If you want to argue that the speedups wouldn't be worth other
sacrifices then that's fine, but you don't seem to be making that
argument.

> 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.

But you've already said that the python compiler doesn't do that.

> 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%).

So in the case where you inlined the code, the program probably would
have been a lot prettier and easier to maintain if there had been a
clean and simple way to do it.  You can call it a trick if you want
to.  

I'm not convinced that it would be "worth it" to have "inline
functions" or "auto-inlined code" or whatever you want to call it.
That's what I'm trying to discuss.  I'm interested in your (and
others') thoughts on the matter.  So far though, I find your claims
that they would be useless unconvincing.

					-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