For example, here are filters for both JS and Python: https://www.techempower.com/benchmarks/#section=data-r20&hw=...
Do note that for most of the "realistic" stacks out there, you'd probably want to filter out all of the micro or no framework approaches, to compare something like Express and Koa against Django and Flask, like in the following link: https://www.techempower.com/benchmarks/#section=data-r20&hw=...
Here's the summary page with composite scores across all tests (though you might also want to filter by data storage solution, for example, MySQL): https://www.techempower.com/benchmarks/#section=data-r20&hw=...
To summarize, the performance from the best to worst currently is:
Composite scores: Koa (JS) > Express (JS) > Flask (Python) > Django (Python)> "more real world scenario" "realistic"
I'm of the opinion that "Real programs may not be representative either".
http://www.larcenists.org/Twobit/bmcrock.temp.html
We have to show that they are or discover they are not.
Of course, if you can, take benchmarks with a grain of salt and ideally do some prototyping and load testing.
Is "exactly" really the situation, or is it that the benchmark does something kind-of like one of the use cases?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
For example, look at a full platform Java Spring Boot example here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
The controller code, the model code and even the repository code are all very reflective of the primitives you'd find in production code.
The only differences would be when you add additional complexity, such as validations and other code into the mix, such as additional service calls etc., but if even the simpler stuff in Python (as an example) would be noticeably slower, then it stands to reason that it wouldn't get magically faster on the basis of less overhead alone.
The exceptions to this which i could imagine would be calls to native code, since the aforementioned Python has an amazing number crunching or machine learning support, but that is hardly relevant to web development in most cases.
Otherwise we risk running into the "No true Scotsman" fallacy: https://en.wikipedia.org/wiki/No_true_Scotsman
In such a case, we'd adamantly claim that these benchmarks are simply not good enough even for educated guesses and we'd have to build out our full system to benchmark it, which no one actually has the resources for - in practice you'd develop a system and then would have to do a big rewrite, as was the case with PHP and Facebook, as well as many other companies.
On the other hand, premature optimization and dogmatic beliefs are the opposite end of the spectrum: you don't need to write everything in Rust if using Ruby would get your small application out the door in a more reasonable amount of time.
There are no easy answers, everything depends on the context (e.g. small web dev shop vs an enterprise platform to be used by millions) and the concerns (e.g. resource usage and server budget vs being the first to market, as well as developer knowledge of tech stacks, for example market conditions of PHP vs Rust).
Regardless, in my eyes, there's definitely a lot of value in these attempts to compare idiomatic interpretations of common logic for web development primitives (serving network requests in a known set of formats).
> … which no one actually has the resources for…
That webpage references "JSMeter: Characterizing Real-World Behavior of JavaScript Programs".
iirc they instrumented a web browser to collect "real-world" data and demontrated that wasn't like the behavior of benchmark code.
That webpage references "A comparison of three programming languages for a full-fledged next-generation sequencing tool" — "reimplemented … in all three languages and benchmarked their runtime performance and memory use."
That's in-practice.
> … you don't need to write everything in Rust if using Ruby…
Performance doesn't matter until it matters.
As-in the home page quote and reference — "It's important to be realistic: most people don't care about program performance most of the time."
https://benchmarksgame-team.pages.debian.net/benchmarksgame/
Python basically using C types and GMP to write C in Python...
Did you? :-)
That Node pidigits program also uses GMP.
Besides those 2, did you notice other JS programs not 50x faster than the corresponding Python programs ?
But everyone knows it is significantly faster than Python. Probably at least a few times for pure JS vs. pure Python programs. Not that it matters, Python is basically glue to run mostly C and C++ programs.
It’s not really what you’d expect for a site called computer language benchmarks game. Each example just calls out to a very fast c library (pcre2) to perform the heavy lifting regardless of which language is being “benchmarked”.
Seems a pretty pointless site.
The other examples have similar nonsense.
No.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
from re import sub, findall
That's where pcre2 is called (or a finely tuned regex c lib)https://docs.python.org/3/library/re.html
pcre2 is not —
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Here's some of a comment from _operator.c
"This module exports a set of functions implemented in C corresponding\n\ to the intrinsic operators of Python. For example, operator.add(x, y)\n\ is equivalent to the expression x+y."
Why wouldn't you expect that CPython regex would "ultimately" be written in C?
Your python 3 one isnt the fastest python 3 solution, it’s this one which uses pcre2
The slower program is an example from that website of a regex program which does not " just calls out to a very fast c library (pcre2)…".
> "... a pretty solid study on the boredom of performance-oriented software engineers grouped by programming language."
I think that's probably the best way to describe it.
Edit to answer yours: There may be less Python programmers that are bored, or less performance-oriented Python programmers.