[jmilosze]

Well of course it is calling C. The point of this argument is that you don't have to go all in and write your code in C to get good performance. You can just write good Python and get almost as fast code as C that will take you 5 times less time to develop.

[rualca]

>>You can just write good Python and get almost as fast code as C that will take you 5 times less time to develop.

In this case we're talking about a >2x slowdown.

The service also has fewer features.

You're talking about development time in a context where development time is largely irrelevant, as this is a service that people reuse and pick based on performance, because lower performance means higher costs to scale enough to meet requirements.

[theginger]

He is comparing a version 4 release of a product used by millions, and a POC I suspect of you took a look at early release of redis performance and features would be a lot closer.

[rualca]

OP specifically did a Python Vs C comparison. Your assertions have nothing to do with the claim behind discussed.

Even so, if you really want to discuss specific technical aspects, you should do well to keep in mind Python's notorious and widely known performance problems, such as those due to Python's GIL, and the fact that even in performance-oriented benchmarks Python lags way behind other languages, specially C

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

If it was easy or possible to mitigate Python's notorious performance issues then we would see the results in these synthetic benchmarks. But we don't, no matter how much time has been devoted to them.

Speaking as someone who writes Python for a living, Python aficionados would do well by avoiding misrepresent Python in ways that a) it's easy to verify and refute, b) goes against it's main technical characteristics. Python is awesome to chug out quick and dirty POCs, exploratory code, glue code that ties together performance-critical parts, utilities, and non-performance critical applications. Performance-critical applications is not, nor it ever was, Python's thing. Once we see Python addictions dos trying to claim that their hammer is the best screwdriver around, we start to sell a losing proposition.

[ImprobableTruth]

>You can just write good Python and get almost as fast code as C that will take you 5 times less time to develop.

Sure, if someone has done the actual core work in C already that is.

[pydry]

Which, for uvloop, somebody already had - for a completely different purpose.

I think most people are usually quite surprised at how concentrated and how generic most hot paths can be. Theres a heavy power law distribution for the linesof code most code spends its time on.

[VWWHFSfQ]

This thing has all kinds of thread safety issues which if were actually addressed would make the implementation significantly larger, and slower. I'm not really sure what the point of this is other than to say that python dicts are pretty fast. But we already knew that

[anentropic]

Redis itself is single-threaded though (or was, it's only "mostly" single-threaded now)

[badjeans]

Yes, but the point is that you can only do that in some special cases like this one.