[kragen]

Typically, computation you do in Python code costs you about 40× as much CPU as if you did it in C. But with Numpy I usually see only about a 4× single-core slowdown after a little optimization work. Many database-backed web services are bottlenecked on the database or text template instantiation, neither of which are really related to Python's CPU efficiency.

As a side note, the most popular databases are getting only a tiny fraction of the available performance on current hardware. I wrote a couple of comments with more details about this a week ago: https://news.ycombinator.com/item?id=44408654

In the manycore world, Python's GIL makes some approaches to scaling across cores unavailable, though that is changing. But I don't think those are usually relevant to web server throughput, just (potentially) latency.

[IgorPartola]

I work with Python quite a bit. Basically you either world where something like a web request takes 40ms to process instead of 20 and that just doesn't matter or you are in the situation where the request takes 2000ms instead of 500ms which is not as acceptable (but might be depending on the UI on top of this web request). At that point your first stop is something like numpy or another C or Rust module that will do the brunt of the CPU-intensive work. Past that, yeah you gotta look at different runtimes. But Python is so fast for prototyping that it might not even be worth it.

I haven't tried it yet but I do wonder about the feasibility of writing code in Python and then having an LLM transcode it to something like C, especially since I know C well enough to do what I want in that directly so I could check the resultant code by hand.

[kragen]

That is in agreement with my experience.

I've had much better luck with LLMs translating code from one language to another than with writing it from scratch.

[pjmlp]

We are not yet there, however I do1 see a future where the target language might as well be machine code, and slowly we will leave the current languages behind.