Live data from Hacker News

We've been lied to: JavaScript is fast

jyelewis.com

41–50 of 86 posts

Re: We've been lied to: JavaScript is fast

#41
post #37
post #13

It was never slow. The event loop is very performant compared to a language with a GIL and a culture of synchronous IO (looking at you, python and ruby), and V8 is amazing. I notice that the author doesn't give any links to claims that JavaScript is slow, and the first two pages of search results are either discussions of how fast JS is or guides to JS performance. Who exactly was lying?

The old JS interpreters were actually quite slow! That's why they made V8 in the first place. Speed was its big selling point.

Oh yeah, sorry, I should have said nodejs (which has been V8 from day one) was never slow. Some of the older browser implementations were shocking.

I should also add a massive asterisk to "never slow", clarifying that it's usually within a couple of orders of magnitude of compiled code, and faster than that for glue language tasks that let it call native code for the heavy lifting.

Re: We've been lied to: JavaScript is fast

#42
post #14

function main() { let myNum = 0; for (let i = 0; i I'm a little surprised that turbofan doesn't JIT that into an empty function, given that it has no return value or side effects.

It doesn't eliminate loops, but it almost certainly is an empty loop after the full pipeline of optimizations and scheduling. I'm guessing the C version is unrolled or even completely eliminated, because LLVM will definitely eliminate empty loops.

Re: We've been lied to: JavaScript is fast

#43

The second code comparison is supposed to point out that the second version. Unfortunately, still not easy enough to read to avoid bugs caused by javascript's "unique" approach. `findSmallestPositiveValue([2,11])` gives the wrong value for the supposedly better function. > Even if the second function takes twice as long as the first, we are in the realm of nanoseconds. How can you possibly know this? You can make eit…

These probably have nothing to do with the speed of javascript as-is, but the whole stack of data and layout of a page that needs to be either loaded from some database and then computed how to layout in a reactive manner.

Javascript is very fast, but what is not fast is the frameworks that use it or the ways people use those frameworks. If people with similarly minded thinking as those who develop desktop only apps with native languages, would write javascript only apps, I would say the performance would be very close.

But many developers have no understanding of how to write performant code, as they have used to just using some heavy frameworks that handle all that stuff for you, so easily you become limited by that thinking.

That is at least my view into this world, where naive web-developers who have like 2 years of software development can get to deploy stuff to production. Iteration speeds need to be fast, so a lot more people are employed without the skills to really understand what is happening, thus resulting in poorly executed services. Or maybe it's just not a priority.

Also, many technically inclined people just don't get it, that what is important is that you can execute a function, the speed is not really so important in the end, even though we would like it to be. We tend to live in a bubble, those who have dwelled deeper into the operating ways of computers, that we think that everybody else is like that too, or should be.

Many are just doing their jobs, and that does not include learning how a CPU or memory works, but it might be limited to learning how a Vue.js framework works or how to use React.

Re: We've been lied to: JavaScript is fast

#44

I've never heard anyone tell me that JavaScript is slow. I remember node.js benchmarks in the front page of hn showing it to be as fast as hotspot jvm. And this was pre 2012. And since node is single threaded, you had to run n.cores instances of your app. For the longest time as a kid what I was lied to was that Java was much slower than Ruby/Python and my perception was painted by the startup times.

Java is probably 10 times faster than JS and Pyrhon.

Re: We've been lied to: JavaScript is fast

#45
That's the most ridiculous benchmark I've ever seen. Real world workloads are absolutely nothing like the example in this blog post.

Also, why ignore memory usage and JS VM startup time? Why ignore the massive dependency tree that comes with JS frameworks? There's multiple factors to consider when assessing language performance. JS is far less efficient than other languages...but that's honestly fine. There are plenty of use cases for the language where your application doesn't have to be incredibly performant.

Re: We've been lied to: JavaScript is fast

#46

JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C version, and more complex code can’t be optimized nearly as well. I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps. You don’t see many web games because the graphics required for games today can’t really…

It's fast now because a bunch of mega-corps (Google, Apple, Microsoft before dropping the ball) put a huge investment in making JavaScript interpreters fast.

mozilla gets no credit at all? According to some old zdnet benchmarks I could google up[1], their IE7's sunspider was result was 22678ms, Firefox 2's result was 12460ms, Firefox 3 RC1 2377ms. So mozilla managed to make their Firefox 3 js engine about 10 times faster than IE7 in sunspider, more than 5 times faster than Firefox 2. Safari at the time was pretty much on par with Firefox 3. That's before any public Google Chrome release (their first release was a few months after Firefox 3 stable). After the Chrome release, js perf mostly became an arms race between Google and mozilla with the other vendors trying to not be left too far behind in the dust.

Of course, in current gen browsers and on current gen hardware, sunspider is so fast it's more noise than measurement.

[1] https://www.zdnet.com/a/img/resize/3062e92bf2f9f018f49723939... Full size image url is broken :P

Re: We've been lied to: JavaScript is fast

#47

JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C version, and more complex code can’t be optimized nearly as well. I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps. You don’t see many web games because the graphics required for games today can’t really…

> You don’t see many web games because the graphics required for games today can’t really be rendered on the web in 20+ FPS

Nonsense. There's nothing wrong with the graphics you can run on the web. Web games flourished before the iPhone. And it seems safe to assume that they died because of the iPhone.

It was a horrific development in the space, since mobile games differ from flash games in being (1) more expensive and (2) worse.

Re: We've been lied to: JavaScript is fast

#49
post #38

Those are some really bad benchmarks. JavaScript is probably like 10x or 100x slower than C or similar languages when you write something bigger and any of the following happens: - the ratio of code size to run time is too big. Then the jit can’t keep up. - you use a lot of value types. Them be structs in C, no need for allocation. In JS them be objects. The JS VM will try to escape analyze them, and it will succeed…

I've been thinking a lot about this over the years. Having been a dyed-in-the-wool Java VM person for years, and then also working on JS, I started to see the marketing speak I blabbed for years just kind of disappear in the face of huge applications. JavaScript, Java, C#, generally all JITed languages will eventually end up exhausting the size of their JIT code caches. You just gotta hope that your hot paths are con…

With Java there's some relation to the native code, so if you reach that point you can use something like GraalVM to get better performance. In fact there's quite a lot of people who check that with large apps, for most cases JITs perform better in runtime and AoT performs better on startup. But for huge apps this might flip.

But the thing is that Java is pretty close to native. Primitive types, object allocation, threads etc. all correlate almost directly to how CPUs and OSs work. So you get a sense of performance and what's expensive/isn't.

With JavaScript there are so many complex abstractions and constructs it's really hard to get a sense of what the final ASM will look like in an optimal case. Unfortunately, some Java changes (e.g. Valhalla) aim to bring some of that lack of clarity into Java. Still, thanks to typing and a simpler syntax Java is MUCH better positioned here than JavaScript.

Re: We've been lied to: JavaScript is fast

#50
post #38

Earlier quoted context omitted.

I've been thinking a lot about this over the years. Having been a dyed-in-the-wool Java VM person for years, and then also working on JS, I started to see the marketing speak I blabbed for years just kind of disappear in the face of huge applications. JavaScript, Java, C#, generally all JITed languages will eventually end up exhausting the size of their JIT code caches. You just gotta hope that your hot paths are con…

With Java there's some relation to the native code, so if you reach that point you can use something like GraalVM to get better performance. In fact there's quite a lot of people who check that with large apps, for most cases JITs perform better in runtime and AoT performs better on startup. But for huge apps this might flip. But the thing is that Java is pretty close to native. Primitive types, object allocation, th…

I agree that with Java you can get close to native performance if you are careful. (I wrote a MCU emulator that beat its C competitor back in 2005, and that's all low-level hackery). But in practice people write a ton of abstraction in Java and programs are quite trashy (i.e. allocate a lot of intermediate objects that are quickly garbage). The APIs and best practices encourage a lot of overabstraction, IMHO, and that leads to big, lumbering programs that struggle to get back to reasonable performance levels with the prodigious efforts of VMs.
Post reply on HN