From time to time, when hiring with candidates and colleagues, I hear bad opinions about JavaScript from “experienced” programmers who are used to writing in C ++, Java, C #, Delphi. I do not participate in discussions on the topic “JS is not a language at all”, but when it comes to efficiency, productivity, speed of development, I like to listen and speak.
I often cite such a thesis - despite all the flaws in JavaScript, now it’s quite a powerful and multi-purpose tool, one of the most important advantages of which for business is the significantly higher development speed. That is, writing code and solving a problem in JS is often much faster than in a “normal” language and the result is quite satisfactory. Add-on over JS in the form of TypeScript helps to reduce the number of bugs. As a counter-argument, I often get poor performance in JavaScript code. I am not a fan of JS, but it became interesting to me - how slow is modern JS in comparison with “adults” compiled languages.
The performance of different languages depends on the tasks, but there are common points, such as memory management, arithmetic operations, which, it seems to me, allow you to get an idea of the performance of the algorithm in one language or another as accurately as possible.
I decided to take some simple algorithm with integer arithmetic and implement it in several languages as identically as possible. My research does not pretend to a serious benchmark, and the more so I do not persuade anyone to urgently switch to JS or C # or any other language.
I chose the task of generating a sequence of primes. Here is the implementation in C:
')
#include "stdafx.h" #include <cstdio> #include <ctime> int main() { int Max = 500000; int nums[100000]; //100 nums[0] = 2; int j = 1; clock_t t; t = clock(); for (int cur = 3; cur < Max; cur += 2) { int half = cur / 2; bool isPrime = true; for (int i = 0; nums[i] <= half; i++) { if ((cur % nums[i]) == 0) { isPrime = false; break; } } if (isPrime) { nums[j] = cur; j++; } } t = clock() - t; printf("Time to gen %d primes (up to 500 000) : %f seconds.\n", j, ((double)t) / CLOCKS_PER_SEC); return 0; }
I also implemented this algorithm in C #, Delphi and JavaScript are completely identical as far as possible. I use Windows 10, so the following tools were used:
for C - compiler from Visual Studio 2019 Community
for C # - .NET Core SDK 2.2.300
for Delphi - Delphi XE Win32 (2010)
for JS - Node.js v. 10.16
Performing the calculations from the above C program took 1.2 seconds on my computer. This is the best result of 4 languages that I compared.
What do you think, in what order did the other languages line up to increase working time and decrease productivity, respectively? What language was the slowest? How strong is the gap between the results of other languages?
In a few days I will add the article with the results, but for now I suggest voting and writing my opinion in the comments.
PS (the next day)
Already accumulated a sufficient result of the vote. Thanks to everyone who voted.
Thanks to those who pointed out the shortcomings of this task for using it as a benchmark.
Those who asked about "how many times tests were run" - I answer "at least 10 times" and this did not affect the distribution of places.
Now about the results.
1. Although the Delphi compiler is quite old and generates 32-bit code, nevertheless this code is native and sufficiently optimal for this task. The gap with the most modern C / C ++ compiler was less than 10%. The result of the program on Delphi is 1.34 seconds (versus 1.2 seconds for C / C ++).
2. Node.js, starting from version 8, quite noticeably pulled up in speed, many people noticed this on many tasks. In this problem, the JS result is 2.15 seconds. That is, this algorithm, being implemented in JS, is less than 2 times lower than the implementation in C / C ++.
3. C # result - (updated) 1.9 seconds when using the list and array. My previous information here was unreliable, since I forgot to make sure that the version compiled into the release was launched (started from the command line). I am really familiar with C # at the “Hello World” level.
30.6% of those who voted for the option “C, Delphi, C #, JavaScript — Delphi does C # and JS” turned out to be right. Another thing is that the difference between the results of C # and JavaScript is very small.
What arguments can explain 15% of the votes for “C, C #, JavaScript, Delphi” and almost 13% for “C, Java Script, C #, Delphi” - I have no idea. That is, in my opinion, 28% voted without imagining what Delphi is.
24% of those who voted for the “C, C #, Delphi, JavaScript” variant apparently expressed the hope that the modern compiler and the C # runtime, despite their architectural features, will still overcome the outdated Delphi compiler. There were comments about how cool Java is now. Nevertheless, compilers that generate native processor code are still a bit more efficient.
Instead of outputIn this experiment, I was surprised by 3 points:
1. Pretty good javascript result (fixed).
2. Inadequately aggressive and even painful (as I think) the reaction of so many readers to a simple suggestion to speculate about the performance of modern programming languages. I don’t know what the reason is - in hate for JavaScript or for me personally, but I would like to understand this reason (in the comments I was already explained - writing Java Script - with a space - causes fits of rage).
3. Some of those who commented bother to write a comment and give references to other benchmarks, but at the same time they found it difficult to formulate their own opinion on a given question, at least on the basis of looking at the pictures on the links they gave. If you follow the benchmarks and you have an opinion about languages, then why not express it? And so it turns out that "I know there is an answer, but what answer is there - I do not know." It seems to me that the effect of the constant presence of a search engine is at hand - it’s possible not to keep knowledge in your head and not even have your own opinion, because you can always google them.
Thanks to everyone who participated in the survey!