
Python is Slow, and I Don't Care - nhumrich
https://medium.com/@nhumrich/yes-python-is-slow-and-i-dont-care-13763980b5a1
======
titzer
If your reasoning is productivity above everything, therefore the only
solution you can think of is Python, I call BS.

As a Googler, I could relate countless stories of systems that were cobbled
together in Python and then scaled up with massive investment, then later
rewritten in C++ or Go, and generally ran with 100x fewer resources. Hell,
from what I can tell, almost all of YouTube was written in Python and has or
is still being rewritten in C++, Java, and Go, saving XX millions of dollars
per year of CPU time.

Sure, prototype with Python. But by the time you get to scaling out a huge
service, it's probably time that you rearchitected the system anyway, and you
should spend the engineering effort to make it efficient.

~~~
rakoo
> then later rewritten in C++ or Go, and generally ran with 100x fewer
> resources

This kind of story comes again all the time, but the most important detail is
always missing: how much of that 100x can be attributed to the language, and
how much can be attributed to _now I know the domain better, I know where the
pitfalls are, how to model the problem, and when I need to optimize_ ? Because
arguably the second one can bring a lot.

~~~
staticassertion
I've written 1 to 1 (algorithm) code from Python to Rust and seen orders of
magnitude performance/ memory difference. This was not a 'rewrite it with
lessons learned' this was 'rewrite it as similarly as possible'. It is the
language (and runtime).

~~~
candiodari
This is why C++ (and maybe Rust, damn I need to learn Rust) will keep existing
forever. If cloud deployments make sense, then optimizing by rewriting into
C++ also makes a lot of sense, as it provides a continuous direct savings:
your bill goes down by a directly quantifiable amount.

------
floatboth
Honestly the "[dynamically typed scripting language] is much more productive
than [statically typed compiled language]" arguments sound like bullshit.

There's just too many things to take into account:

\- the developer's experience with a particular language

\- the developer's experience with the problem domain / understanding of the
task / etc.

\- time spent writing the code but also time spent debugging it

\- time spent debugging a few weeks later when it suddenly breaks in
production (dynamic typing often fails there)

Really, the most productive language is the one you're most familiar with.

I still use Python and Ruby for various tasks (mostly for scripting, command-
line apps, simple services). Their main advantages are their library
ecosystems and portability* . But they aren't very good for serious app
development. Even when you feel like your business logic is extremely simple,
you WILL get that weird null (sorry, None) or completely unexpected exception
in production.

* I mean, you can easily run a Python script on, say, an iBook G4 running OpenBSD/macppc, or an old ReadyNAS with Debian/SPARC, or your MIPS home router. I like obscure hardware :)

------
wyldfire
PyPy is mentioned in the article but omitted from the "Lets review some of the
main points" summary.

> If Python is your bottleneck (you’ve already optimized algorithms/etc.),
> then move the hot-spot to Cython/C

After "If Python is your bottleneck", I'd just add "then try PyPy because
there's a decent chance everything will Just Work and Be Faster." Sometimes
you run into portability bugs in your code, other people's code, and sometimes
you run into compatibility problems. But most of the time it Just Works.

------
duglauk
"A company’s most expensive resource is now its employee’s time. Or in other
words, you. It’s more important to get stuff done then to make it go fast."

Now take this sentence and apply it to the end user of your software.

~~~
nhumrich
Maybe I'm daft, but I don't quite understand what your getting at.

~~~
throwaway2048
translated: We dont care if our software runs like crap for you because our
time is more important than your user experience.

~~~
nhumrich
I think your misunderstanding the tone of the article. I mention how the
bottleneck is usually not the language. It IS important to optimize, but its
important to understand where the real issue is. I later explain that things
have to be only "good enough". And I also explain how you CAN optimize python
when it IS to slow for your users.

~~~
khedoros1
From their viewpoint: The biggest cost for the company that implements
something is their employees' time, and that's likely true of your customers,
as well. Your costs are easily measured by you; the customers' costs aren't.
Reading the article, it's a little grating that their costs aren't given the
same weight as yours.

From your viewpoint: You've got a large constant X (representing time taken
doing something un-optimizable like I/O), a small constant Y (representing the
"language multiplier"), and a small constant Z (representing CPU-heavy work).
So you've got something like Time=N(X+Y*Z), which for values of Y and Z in
your work, means that X is by far the largest timesink.

From my viewpoint: You're talking past each other, imagining different
constants. It's also interesting to me that a program is still considered
written in "Python" if the interesting parts are actually in C, and called
from Python. You make points that I agree with about premature optimization,
but I think the way you wrote your article opens it to easy misinterpretation,
since everyone will view it through their workloads (which may vary strongly
from yours). I would've limited the discussion explicitly to the kinds of use-
cases you're thinking of.

------
zwieback
I've read this exact article at least a dozen times over the last 25 years
(replace Python with some other language).

More interesting than the actual content is the question why this topic is of
such perennial interest, is it a feeling of inferiority of programmers working
in higher-level but slower languages? Or frustration with coworkers wasting
time on premature optimization? Probably a mixture of both.

------
cdelsolar
A counterexample is Celery when used for things such as network IO. You can't
scale horizontally because each process creates a database connection, and
you'd need a giant database server just to handle a bunch of network IO. The
Celery code would probably have to get its parameters from a cache or
somewhere that's not the database, but this breaks their suggested use case of
accessing the database models when the task actually executes.

~~~
zlagen
I guess you could use a connection pooler like pgpool-2?

------
lutusp
Most of the comments here contrast python _or_ a faster language. I can't
count the number of times I've prototyped a complex algorithm in Python, then,
satisfied that the idea was sound, translated it into a faster language for
release.

------
est
You should care. PHP7 cared about speed and it was a success.

Python 3 cared pretty much everything else except for speed and now 10 years
had passed it didn't go anywhere.

~~~
metaphorm
Python 3's long road to full adoption is much more about mishandling major
breaking changes than it is about lack of performance optimizations.

~~~
snovv_crash
If Python3 was 5x as fast i can tell you right now that people would be
scrambling head over heels to migrate. Instead they are migrating because they
no longer have support for their libraries, or because someone said they were
a bad person for not keeping up with the latest cool thing.

~~~
kungtotte
There is a significant amount of people stuck on 2.7 due to platform
restrictions; quite a few OSes still under support are using 2.7 as their
system Python and there's no incentive to upgrade these systems.

Even if Python 3 was 10x as fast, sysadmins would hesitate to put what's
effectively an unsupported version of Python on their systems.

Massive performance increases would help to sway those who have the freedom to
move to a different Python without being locked to their system, I agree about
that much.

------
ScottBurson
Or you could use Common Lisp, and have productivity _and_ performance.

(I know -- the libraries aren't as good.)

------
ram_rar
Speed and Concurrency Matters! Golang has outperformed python in both these
areas. If it wasn't for the rich ecosystem for data analysis/ Devops libraries
(Scikit, Numpy, Scipy, Ansible) in Python. I would have long moved to Golang.

------
justforFranz
The relationship between the code and the programmer is more important &
expensive than the relationship between the code and the computer.

------
imode
not caring about performance destroys faith in projects. if the things we
write can't be as performant as we like, we'll use a different language and
your project will fade.

pretty simple concept. surprised that people don't understand that.

(mind you, python is about as performant as I like for the tasks I use it for,
so ymmv with the above.)

~~~
tachyonbeam
I think part of the issue is that Python has been the king scripting language
on the desktop. It's been quite successful, and so all these people go "you
see, performance doesn't really matter, since Python is succeeding without
it".

What they fail to realize is that JS, for instance, can reach about 50% of the
speed of C code nowadays. If Python could be that fast, you could use it to
write videogames and all other kinds of software that you can't realistically
write in Python today. It could displace a lot of C++ code. The poor
performance of Python is actually limiting its adoption.

Python has poor performance, and a very poor handling of multithreading, at a
time when single-core performance is stagnating. I think it's inevitable that
people will start migrating away from it eventually. I mean, if you could have
something like Python, but 20x better performance, would you take it?

------
BenFrantzDale
Along these lines, the first major Python project I used I was amazed Python
was used. It's a real-time 3D reconstruction system operating on a live video
stream. That was ten years ago.

There was some assembly and C at the very core, but every point generated was
a Python tulle at one point in processing.

------
moolcool
I see a lot of concern online about Python's performance, but at the same time
I don't see a lot of people talking about things like Iron Python or Jython.
Is there a reason these solutions aren't adopted more?

~~~
jackmott
Probably in part because of the attitude that performance doesn't matter.

------
jackmott
From my comment on the blog article:

Allow me to point out some important points of disagreement here.

“Speed no longer matters”

While computers are faster, the expectations of users are also higher. New
monitors today have 14,745,600 pixels and that is still growing fast, that is
7 times more than 1920x1080 which was the norm just a couple of years ago.
That means for any app involving UI or graphics, you have significantly more
work to do. This same trend applies to processing data, as databases are also
bigger, complexity and amount of features expected has also increased. To keep
up with that you can’t throw away cycles.

While computers are faster, many more people are doing computing on small
devices like phones and tablets where battery power is a precious resource,
and slow code wastes battery life faster.

The cost of scaling server side infrastructure can seem cheap with a naive
analysis, but high performance code can not only mean fewer servers or cloud
services to buy, but also a simpler architecture. As soon as you have to scale
beyond 1 web server for instance, you now also need to worry about load
balancing, and a host of other issues. High performing code can keep you on a
single server for an amazingly huge workload.

Lower latency has been proven to make money
[https://blog.gigaspaces.com/amazon-found-every-100ms-of-
late...](https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-
them-1-in-sales/)

Another point of disagreement is the idea that this performance his we take
with interpreted Python is completely unnecessary. Exactly the same language
can exist in JITted form, and does, and it should be brought up to be the
default and only way of executing python. There also exist plenty of similarly
nice and expressive languages that perform better (OCaml, F#, etc)

Every day I am annoyed by slow software, and until that stops I will never
accept the argument that performance doesn’t matter.

~~~
nhumrich
> Exactly the same language can exist in JITted form, and does, and it should
> be brought up to be the default and only way of executing python

Yes, PyPy, Jypthon, etc. exist and they can be faster. If you want to use
those, then great, do it! But a JIT is not faster in all cases, only some
cases. Python is first and foremost a scripting languages, and for a lot of
the simple script cases, CPython is faster than a JIT version. It doesnt make
sense to make that the default.

~~~
jackmott
Being first and foremost a scripting language doesn't _mean_ anything.

If the argument is that for really short programs the iteration time when
building and running is faster with the interpreter, because you don't have to
build, I can't see how this matters. It would be a sub microsecond difference
for short scripts. If it isn't, make a better JIT. (or even better, native
compile it, as all things should be in my fever dreams)

