Python and the need for speed

[bart4858 at gmail.com]

On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano  wrote:
> On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote:
> 
> > high level languages like Python should make it difficult, if not
> > impossible, to write sub-
> > optimal code (at least in the blatantly obvious cases).
> 

> Here's another example:
> 
>     answer = 0
>     for i in range(10):
>         answer += 1
> 
> instead of 
> 
>     answer = 10
> 
> So... how exactly does the compiler prohibit stupid code?

Actually, an optimising C compiler (not one of mine!) probably could reduce that to answer=10. And eliminate even that if 'answer' was never used.

But that's not really the issue here. Assume that such a loop /is/ doing something more useful. The problems with Python (last time I looked anyway) were these:

(1) If answer was a global variable, then it needs a symbol table lookup to find out what it is. That would not happen in a static language, or a less dynamic one, as you already have the address.

And this lookup happens for every loop iteration.

(2) There is also 'range', which could have been redefined to mean something else, so /that/ needs a lookup. The byte-code compiler can't just assume this loop is to be executed 10 times.

(3) This was fixed long ago but at one time, even when 'range' had been established to be a range, it involved constructing a list of items (10 here, but it could be a million), and then iterating over the list.

This might seem crazy, but it might have been exceptable for a script language at one time. Not for a general purpose one however.

(4) Python's integer types being immutable, the += operation means evaluating the result, then creating a new integer object and binding 'a' to that new value. (Correct me if I'm wrong.)

These are all things the language could point a finger at before blaming the user for writing inefficient code.

The problem is also the language encouraging people to use high-level but inefficient methods, as the emphasis is on productivity and readability** rather than performance. In fact most users probably have no idea on what is efficient and what isn't.

If I wanted to work with the code for character 'A' (ie. the integer 65), in another language it might represent it as 'A' which is mapped to 65. In Python, 'A' is a string. To get the integer code, I have to use ord('A'). To do that, it has to look up 'ord', than execute a function call... In the meantime the more static language has long since finished whatever it was going to do with that code.

(** Although I find code full of class definitions, one-liners, decorators and all the other esoterics, incomprehensive. I'm sure I'm not the only one, so perhaps readability isn't too much of a priority either.)

-- 
bartc