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

[Nick Coghlan]

On 27 January 2016 at 03:35, Sven R. Kunze <srkunze at mail.de> wrote:
> I completely agree with  INADA.
>
> 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.

Umm, no, that's not how this works - developers contribute to
community driven projects for their *own* reasons. Nobody gets to tell
them what to do unless they're paying them.

Micro-optimising a poor algorithm won't deliver macro level
improvements because macro level code uses things like space-speed
trade-offs to improve the algorithmic efficiency (as in the example of
applying functools.lru_cache to a naive recursive fibonacci
implementation).

Victor's work on FAT optimiser is interesting because it offers
opportunities to speed up even code that is already algorithmically
efficient, as well as making CPython a better platform for
experimenting with those kinds of changes.

More generally though, much larger opportunities for improvement lie
in persuading people to *stop writing code*, and instead spending more
of their time on finding and assembling code other people have
*already written* into solutions to interesting problems. *That's* the
kind of improvement that turns enormously complex problems like facial
recognition into 25 line Python scripts:
https://realpython.com/blog/python/face-recognition-with-python/

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia