Python is Slow, and I Don't Care | Hacker News Reader

Python is Slow, and I Don't Care

medium.com

49 pointsnhumrich64 comments

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.

I don't think there's much sense in using Google as a proxy for anything really. The scale at which Google operates is in another universe.

In no ways am I saying Python is the only solution. Moreso that Python is A solution. Sure, other languages and things exist. After all, no silver bullet.

Also, you are saying that google hit a scale where it really WAS expensive to use python. Twitter had a similar issue with Ruby. That makes sense for a huge company like google, twitter, etc. But for most of us, our companies/projects will never get the scale that youtube has.

> 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.

In my own deep experiments with simplex noise generation in c++ and C#, C++ allowed me to go ~10x faster and it was 100% due to the 'language' (and associated ecosystem).

Domain knowledge for me is higher in C#, both were optimized as far as I could figure out.

There are dozens of cpu instructions you can't even make happen in most runtime GC languages. It is banananastown.

You could get similar performance with a C or C++ extension, or by using Cython. 99% of your application is probably not generating simplex noise or doing anything CPU-bounded like that.

It's about half and half, 50x comes from the language and 50x comes from experience. The important part is to add those factors together by good management.

The math here doesn't really make sense, factors multiply, so if there were two 50x factors the total improvement would be 2500x. In other words if one factor is 50x, the other one must be 2x to get 100x total.

This is useless pedantry. You know what they were trying to say: The improvement can be attributed equally to using a more suitable technology and to better knowledge of the problem domain.

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).

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.

> 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.

If you reach YouTube scale, maybe the CPU savings > developer time.

But I don't think you will reach that scale if you start with C++. Completion will outpace you in no time.

There are middle grounds between c++ and interpreted Python that have the same productivity as python and better performance.

Correct. Like writting in python, but optimizing the "bottlenecks" in C/C++/Cython

Or choosing a language that's inherently somewhere in the middle (go).

Why not just compile/JIT the python, always? I feel like I'm taking crazy pills! :) Even when you write the hot bits in C++ you still have a python interpreter thrashing the CPU caches and using up ram.

and now you have to context switch in your head more often, and the build process is more complex, and usually there is a cost when you do the FFI.

If you are talking about PyPy (I presume you are?), then two issues are that it can in some cases be slower, and also C libraries such as Numpy / SciPy are not simple to use with PyPy (I think some of Numpy has been translated, but there are many useful C libraries for Python).

Absolutely, but in the end it all depends what problem you are trying to solve, and which stage you are on.

If you are starting a new startup, with Python or Ruby or PHP you may be able to try 2-3x ideas in the same time. Which means 2-3x more chances of succeeding.

If you are adding a new service to an existing businesses, it may worth the time investing in some middle-ground.

If you are google or facebook, I guess rewriting everything makes sense from financial point of view.

But if those system were developed in another language, maybe by the time they were released there would not be any market demand for it anymore. I've seen it happen where everything is meticulously performance optimized in C and by the time it is released it is fast, snappy, scalable but by then the market has moved on and nobody wants to use it anymore.

Often "We moved from X to Y because X is slow" is seen as a failure of X, but it is not. It could mean the feature was deployed quickly, caught on and has customers which want to use it. So it can be a testament of how productive X is.

+1, not speaking for Google

With large systems you want assurances at compile time, something that Python can't give you much of. When you have a huge system with many modules that interact in ways you can't expect anyone to map out without staring at a lot of code, it pays to have a stronger type system and fewer runtime errors.

For experimentation and small-scale work, Python's great. Single client application? Fantastic (e.g Dropbox). Giant web service or distributed application? Starts to show its ugly sides quickly.

Well, there are two ways of looking at this: 1. Decision to use Python created unnecessary extra work (your point); 2. Executing (not just prototype) with Python, then re-writing and re-optimizing your code in a 'leaner'/lower-level language is a valid approach given that's how Youtube and other highly successful Google products and services evolved.

I think both are valid approaches depending on your application, available resources, nature of incentives, and the speed at which your market moves.

I bet the youtube founders would disagree with you. They probably do not regret launching it quickly in python, selling it to Google for over a billion dollars, and letting Google spend the next decade rewriting it.

If they didn't sell, they would have had to do the rewrite.

There are plenty of future YouTubes who don't want to be acquired and instead are looking to be long term companies. They'd do well to avoid the pain and cost. There are ways to achieve velocity and maintainability, they're not mutually exclusive.

As others' comments, it's totally different maintaining a successful business from launching one. The decision should be based on what value the language can provide.

I'm in a very python heavy company, and maintains the python architecture that are being used on hundreds of servers. The ugly part(lack of restriction, multiprocessing, distribution) quickly shows why it's not suited for very large system.

But I'm curious at which point, we would be so annoyed as to decide to rewrite the whole stuff.

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 :)

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.

"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.

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

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

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.

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.

Maybe this is saying the same thing, but I interpreted it as "If a handful of developers write an application that millions use, then saving a few seconds per user can add up."

I've seen this applied to the Linux kernel, where saving a few microseconds in a system call, when multiplied out to the billions of machines running Linux, saves hundreds of years of CPU time.

With that said, most services don't have as many users as Linux.

It runs like crap, but still saved an hour a day over doing it by hand.

Does the fast version save you more time than it cost by not being available?

https://public.wsu.edu/~brians/errors/your.html

You can only optimize variables (and outcomes) under your control. Coordination is hard, and that's marketing's job to figure out.

If the software is better than anything else available, then the user is optimizing their time within their own constraints. If the users complain that it's too slow and you lose users as a result, then go ahead and optimize. But slow and working is better than fast and imaginary.

Also, you write the software for X minutes and run it for Y. If cost(X) < cost(Y) e.g. Because Y is very large for long running software, then higher performance will save money. Of course it can be difficult to know when this will be true especially in advance...

As a software user, is completely agree with you! I get frustrated by badly performing software so often I regularly wonder if I'd be happier doing something that relied less on shitty software.

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.

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.

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

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.

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.

Ya, I guess the title is slightly misleading. But the point is that speed isnt everything. I will still use Python regardless of it being slow. That being said, Python3 is actually faster than python2 for most things, IIRC

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

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.

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.

I sincerely doubt that. PyPy is advertised as being about 7x as fast ad CPython and yet it also has incredibly low adoption rates because of potential breakage and incompatibilities.

Not really true.

Python 3.6 is basically at speed parity with Python 2. There are a few outliers, but in most cases 3 is as fast or faster than 2.

Python 3 adoption is exactly where the devs wanted it to be 10 years later. Almost all major libraries have been ported. Python 3 adoption is only growing. More than 30% of new projects use it. Expect that to grow substantially as 3.6 is adopted.

"didn't go anywhere" is therefore FUD.

The Python 3 debacle has pretty much nothing to do with performance from what I understand.

Isn't Python3's primary issue that it killed developer productivity?

How would it do that?

Major project just to stay in place. And then all the modules that aren't ready. Basically tons of work just to get the same result. Infinitely unproductive.

That's a very weird argument. I pretty much exclusively use Python 3, so to me it seems hugely successful, where as I didn't even know that PHP7 existed.

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

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

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.

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

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.)

> if things we write can't be as performant as we like, we'll use a different language

I think you are referring to the fact that devs LIKE speed. And they want things to be fast. I mean, your right. We like speed. Probably a lot more than we should. But those who only care about speed simply wont have as successful careers as those who care about productivity (10xers?), unless your lucky enough to be put on a project that is designed entirely for speed. Lots and lots of tools exist that are "slow", but we use them over faster alternative's because of the features they provide. One simple example is IDE's. I think its pretty narrow-viewed to say all projects will fade because they aren't "as fast as they can be". Everything only needs to be fast enough.

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?

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.

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?

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

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...

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.

> 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.

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)

Reply on news.ycombinator.com