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

Stephen J. Turnbull stephen at xemacs.org
Tue Jan 26 02:16:15 EST 2016


INADA Naoki writes:

 > For example, http://benchmarksgame.alioth.debian.org/u64q/php.html
 > In Japanese, many people compares language performance by
 > microbench like fibbonacci.

True enough.  But as a teacher in a Japanese engineering school, I am
ashamed to see that posted to a public list.  We Japanese ;-) need to
get over that tendency (and not just in programming, my own biggest
battle is against those who worship goodness-of-fit statistics).  Our
universities are doing an awful job at getting "big picture thinking"
across to our students.

I see that you respond that you're talking about "base language
performance" which is a big improvement over blind faith in micro-
benchmarks, but still it's a matter of pulling your nose back from the
bark so you can see the tree.  At least from the point of view of the
computations the people around me are doing with these languages, you
still miss the forest.

 > While performance is not a matter when choosing first language,
 > slowest of three makes bad impression and people feel less
 > attractive about Python.

My school is the one that Matz graduated from (different department),
and as far as I can see (which is pretty local, I admit), Python is a
clear first and growing as a teaching language and as a glue language
for research computations.  Java is second for both[1], Ruby is rare,
and PHP just isn't on the map.  I see some lab home pages using
Ruby-on-Rails, and a couple of Mediawiki installations and the like
based on PHP.

For me personally, PHP and Ruby are both unusable for *performance*
reasons: I need something like Pandas, which is based on NumPy, and at
least the last time I checked a couple years ago Ruby had no
equivalent to NumPy, let alone Pandas.  (For PHP I asked the nearest
PHP fanboy web programmer, so I could be way wrong about no efficient
computation for PHP.)

At least as used at this university, I just don't see a performance
issue that Python needs to be specifically worried about.

That said, optimization is important, and IMO anything that allows 1%
of people currently writing (and debugging ...) modules in C for
performance reasons to write them in pure Python instead is a win.
But to me, relieving programmer pain, not microbenchmarks, should be
the performance measure we care about (even if others do care about
those benchmarks).  Measure them, yes, but focus on them only when
we're pretty sure that poor benchmark numbers are associated with
programmer pain.


Footnotes: 
[1]  Java was clearly first as a teaching language until 2010 or so, and
since most of our grad students and assistant profs were students here
in that era, I suspect its persistence is just the inertia that goes
with academic nepotism.



More information about the Python-Dev mailing list