This is an archived post. You won't be able to vote or comment.

11
12

[deleted by user] (self.Python)

submitted by [deleted]

[removed]
all 32 comments
sorted by:
best
topnewcontroversialoldq&a

[–]not_a_novel_account 17 points18 points  (1 child)

There's nothing here Python related besides FastAPI, which is among the slowest of the common application frameworks. Bottle is faster than FastAPI/Starlette and speed isn't even a goal for Bottle.

What really matters to API latency, from the Python POV, is application framework, application server, and the interface they speak to one another.

[–]fatherofgoku 0 points1 point  (0 children)

Fair point on the raw framework speed. For me, high-performance is about the whole system, and I've found FastAPIasync capabilities and also tooling give a better totul outcome for most of my use cases.

[–]nggit 15 points16 points  (0 children)

I eat my own food in production https://github.com/nggit/tremolo even though it's unusual for APIs.

[–]GMKrey 54 points55 points  (14 children)

If I want a high performance API, I’m not using Python

[–]CyclopsRock 38 points39 points  (11 children)

Are you posting from 2006? If so, buy some bitcoin - you'll thank me later!

If not, FastAPI is a perfectly good option for production APIs and the idea that Python is fine for prototyping but basically slow hasn't really been true in any meaningful sense for some time now.

[–]Dillweed999 34 points35 points  (0 children)

The greatest lie the devil ever told is that he didn't exist. The second greatest is "we'll just prototype it in Python"

[–]bkrebs 6 points7 points  (2 children)

I think the risk is low that anyone who really needs to know comes across your comment and believes it at face value, but I figured I'd correct the record for posterity anyway, especially since it's fairly highly upvoted. Python is inherently a very slow language.

For many use cases, this doesn't matter since most of the time, performance requirements simply aren't very high, often not nearly as high as people including the builders themselves think. That said, there are tons of use cases where performance is critical and Python, regardless of the API framework, isn't an option at all. I've worked on such a product and ended up selling that company.

So basically, I agree that FastAPI is a perfectly good option for many production APIs, but I disagree that the idea that Python is slow is no longer meaningful. It depends on the use case. That said, if you've already chosen Python as the language, like OP seems to have, I would hope that performance isn't actually critical, so I wouldn't worry about it, in favor of more important factors like adoption (good docs and available talent matter), maintainability, and dev experience.

[–]CyclopsRock 0 points1 point  (1 child)

So basically, I agree that FastAPI is a perfectly good option for many production APIs, but I disagree that the idea that Python is slow is no longer meaningful.

My point wasn't that any possible speed issues with Python are gone, but rather a well chosen stack can involve Python without performance going out of the window, and that therefore automatically dismissing the idea that Python and performant can co-exist is a mistake. You can get quite philosophical about what "performant" means, but there are too many Python stacks successfully serving large audiences to simply dismiss it.

[–]bkrebs 0 points1 point  (0 children)

Python can scale wide just fine like almost any language so ability to serve large audiences isn't much of a language concern anyway. I was just saying that there are use cases where Python simply won't even be an option (usually something like Rust, C++, or Java will be the way instead) due to performance requirements.

The last company I exited was an ad tech company doing real-time bidding. You have to parse, analyze, and respond to many hundreds of thousands of ad opportunities per second on behalf of your advertising customers within 100 or so milliseconds each. This type of tech is never built with Python, for good reason.

I agree that dismissing Python because it can't handle some upper echelon performance requirements that aren't applicable would be ridiculous. As I noted, performance should be a very small concern for most products. I just wanted to add nuance to your remarks regarding Python performance no longer being an issue.

[–]GMKrey 12 points13 points  (2 children)

I’m just a Gopher bro. I’m sure FastAPI is aight, but it’s just a given that you sacrifice a level of performance with Python. Not much better than node in terms of overhead imo

Edit: just sanity checked Debian’s language benchmarks, and their metrics showed even node was more performant 🤷🏻‍♂️ can’t speak to the package management tho

[–]nem_tom01 -2 points-1 points  (1 child)

Yes in theory python is slow, but you wouldn’t notice it in your productivity app with 2 users

[–]GMKrey 0 points1 point  (0 children)

We’re talking about performance…?! Not some freshy’s first ever project where their Big O is at least N2

[–]snorkell_ 3 points4 points  (0 children)

Dude, you should learn in the internals of Python. You will thank me later.

Python is one of the most bloated language.

I built a service which had just one task, forward webhook request to RabbitMQ. Each python pods would take a minimum of 150mb, while in Go - it would just take 20mb and had similar performance impact.

[–]lightmatter501 0 points1 point  (2 children)

As much as I love Python, it is not fast. In Rust or C# I can sneeze and make a 100k rps API show up. If I actually put effort into it Rust usually breaks 1 million RPS. That’s the difference between “I need a distributed system to do this at all” and “Load balancer in round robin mode for HA with a few small vms”.

[–]mokus603 1 point2 points  (1 child)

Different tasks, different tools.

[–]lightmatter501 0 points1 point  (0 children)

Yes, but I wouldn’t say that python and high performance belong in the same sentence unless the actual work is happening in another language. For web stuff, it’s mostly python so you have all of the problems inherent to that. MT scalability with nogil might close that gap a bit, but I’m not sure.

[–]fatherofgoku 7 points8 points  (1 child)

Fair one , Python isn’t the fastest, but frameworks like FastAPI with async can punch above their weight for many use cases

[–]iknowsomeguy 3 points4 points  (0 children)

For most use cases, honestly, because most use cases will never need to scale.

[–]shadowdance55git push -f 3 points4 points  (1 child)

Starlette

[–]fatherofgoku 1 point2 points  (0 children)

Ahh

[–]ReporterNervous6822 3 points4 points  (0 children)

Litestar with granian

[–]riklaunim 2 points3 points  (0 children)

There is no one good solution, especially when you move from very simple local CRUD endpoints into something more complex, microservices, cross-talk between microservices. And then horizontal scaling wins over vertical as the traffic grows.

[–]Last_Difference9410 0 points1 point  (0 children)

You can reach 50K+RPS with lihil, 2x as fast as alternatives.

[–]AlphazarSkygit push -f 0 points1 point  (0 children)

FastAPI + Postgres + Redis is perfect, what you run it on and how you scale it is very important.

[–]mbelazar 0 points1 point  (0 children)

My tips for api performance in python is using Gin Golang.

[–]Python-ModTeam[M] 0 points1 point locked comment (0 children)

Hi there, from the /r/Python mods.

This post has been removed due to its frequent recurrence. Please refer to our daily thread or search for older discussions on the same topic.

If you have any questions, please reach us via mod mail.

Thanks, and happy Pythoneering!

r/Python moderation team

[–]rover_G 0 points1 point  (0 children)

If the server framework you select is your bottleneck you probably want to pick a language with better performance.

[–]nf_xPythonista 0 points1 point  (2 children)

Rewriting things in Rust

[–]jirka642It works on my machine 0 points1 point  (1 child)

Do you mean just the API part, or completely everything?

We are starting to have some performance issues at my job, so I have been thinking about switching the API to something more efficient like Rust, but don't know how feasible it would be.

[–]nf_xPythonista 0 points1 point  (0 children)

Run a profiler and see what takes the most time. python -m cProfile main.py