[Python-Dev] FAT Python (lack of) performance

[Terry Reedy]

On 1/26/2016 12:35 PM, Sven R. Kunze wrote:
> I completely agree with INADA.

I an not sure you do.

> It's like saying, because a specific crossroad features a higher
> accident rate, *people need to change their driving behavior*.
> *No!* People won't change and it's not necessary either. The crossroad
> needs to be changed to be safer.

Safer crossroads tend to be slower unless one switched to alternate 
designs that eliminate crossing streams of traffic.  Python is safer, in 
everyday use as well as in artificial benchmarks, and is slower as a result.

Languages that don't have integers but use residue classes (with 
wraparound) or finite integer classes (with overflow) as a (faster) 
substitute have, in practice, lots of accidents (bugs) when used by 
non-experts.  Guido noticed this, gave up on changing coder behavior, 
and put the expert behavior of checking for wraparound/overflow and 
switching to real integers (longs) into the language.  (I forget when 
this was added.)

The purpose of the artificially low input to fib() is to hide and avoid 
the bugginess of most languages.  The analogous trick with testing 
crossroads would be to artificially restrict the density of cars to mask 
the accident-proneness of a 'fast, consenting-adults' crossroads with no 
stop signs and no stop lights.

> Same goes for Python. If it's slow using the very same piece of code
> (even superficially), you better make the language faster.
> Developers won't change and they won't change their code either. Just
> not necessary.

Instead of making people rewrite fib to dramatically increase speed, we 
added the lru-cache decorator to get most of the benefit without a 
rewrite.  But Inada rejected this Python speedup.  An ast optimizer 
could potentially do the same speedup without the explicit decorator. 
(No side-effects?  Multiple recursive calls?  Add a cache!)

> Btw. it would be a great feature for Python 3 to be faster than Python
> 2.

We all agree on that.  One way for this to happen is to add optimizers 
that would make Python 'cheat' on micrebenchmarks

-- 
Terry Jan Reedy