4 ms·

> Javascript is plagued with idea that it is slow while it is not. I benchmarked a hello world in .net and node/express, and the .net version was multiple orde

> Javascript is plagued with idea that it is slow while it is not. I benchmarked a hello world in .net and node/express, and the .net version was multiple orders of magnitude faster than the node/express version. That's a starting point, and as you add more logic, that gap only grows in my experience. Javascript may be fast _enough_ for many cases, and in a tight JIT loop it may be faster again, but by any measure, js is not quick.

geysersam 4y ago
No realistic, decently written, js application would be "orders of magnitude" faster if rewritten in .net.
- maccard 4y ago
  And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever seen say - js is significantly slower. One example is the techempower benchmarks Fortune section[0]. It's a fairly basic app, but it tests a full stack web app in multiple languages, and it's pretty clear that js is fimrly in the middle of the pack, far behind the compiled options. If you have any sources to the contrary, I'd love to see them. [0] https://www.techempower.com/benchmarks/#section=data-r21&test=fortune https://www.techempower.com/benchmarks/#section=data-r21&tes...
  - LunaSea 4y ago
    JavaScript ranks higher than C# in your benchmark.
    - maccard 4y ago
      See my other response here https://news.ycombinator.com/item?id=33224873 https://news.ycombinator.com/item?id=33224873
- jesse__ 4y ago
  Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.
  - azakai 4y ago
    There is often a speedup, but maybe not by orders of magnitude. I've usually seen 2x-3x or so.
  - geysersam 4y ago
    Comparing a pure js implemention to code using opengl or webgl, I imagine several orders of magnitude difference is likely. But a decent js implemention of 3D graphics-something would use one of the available tools for such applications. Making the difference considerably smaller. Or is you experience different?
    - jesse__ 4y ago
      I've worked with a couple of the 'decent JS implementation of 3D graphics' libraries and, although they're not all like this, the ones I used were not built by people with experience doing low-level performance work. As such, they made some poor architectural decisions that prevented users of the libraries from doing some very basic optimizations that would have increased perf significantly. The three major blockers I remember were: 1. Render contexts are created on the main thread and the user of the library gets no control over this. This means all driver overhead and library function calls block the main thread, which matters a lot when trying to hit 8ms/frame. 2. Loading textures asynchronously (in another thread, not Javascript async/await) was straight up impossible due to poor architecture. This means app startup was 500ms instead of 5ms. Maybe not a big deal to you, but our use case necessitated quick (a few frames at worst) startup. 3. The renderer used a scene graph, which was hilariously slow to traverse for large numbers of objects. Impossible to optimize by anyone as far as I can tell. Scene graphs just don't work well in JS.
kaba0 4y ago
I’m sorry, but I simply don’t buy that. You either measured something unrelated (e.g. framework), or it was a faulty benchmark for some other reason.
- maccard 4y ago
  I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21
  - LunaSea 4y ago
    JavaScript is ranked 5th on the ranking you linked to. 4 ranks before .Net.
    - maccard 4y ago
      I was hesitant as to how much I should go into this because you get into the semantics of the benchmark but this [0] thread goes into why - that particular implementation doesn't behave the same way as the other implementations, it uses a different db driver that doesn't synchronise, which won't be allowed in the next version of the benchmarks. Techempower publish regular snapshots of their benchmarks at [1], and if you look at any of the snapshots that aren't the last published set where the discrepancy was fixed you'll see that all of the js implementations lag far far behind. [0] https://github.com/TechEmpower/FrameworkBenchmarks/issues/7289 https://github.com/TechEmpower/FrameworkBenchmarks/issues/72... [1] https://tfb-status.techempower.com/ https://tfb-status.techempower.com/
      - xaduha 4y ago
        Are you sure about your conclusion though? Apart from just-js missing in action in last 3 runs, here it's just fine https://www.techempower.com/benchmarks/#section=test&runid=ecfbe3c9-f577-4836-9403-41f9120dfc6e https://www.techempower.com/benchmarks/#section=test&runid=e...
acdha 4y ago
You’re not wrong but I do think it’s important to remember the context: people don’t tend to write math-heavy code in classic JS (there’s a side discussion about WASM now) so relatively few apps bottleneck on CPU - it’s wild when you see people going on about how they need to switch frameworks based on some microbenchmark of request decoding when 99% of their request processing time is some kind of database. I’ve seen more Node apps blow up on RAM usage than CPU because someone thought async would magically make their app faster without asking how much temporary state they were using. Where I think there’s more of a problem is cultural: similarly to Java, there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them.
- liuliu 4y ago
  "Relatively few apps bottleneck on CPU" is a very 2010 opinion. With fast intranet (100Gbps+) and SSD, running business logic can become the bottleneck in many cases. Unfortunately, I don't have readily available data to back up my claim neither.
  - acdha 4y ago
    I’m not saying it can’t happen, just that it’s pretty rare. SSDs are not infinite capacity and 100G networking isn’t common even in data centers - and more to the point, what really matters is latency: how many cycles can your CPU exercise in the time it takes for a round-trip network request is usually orders of magnitude greater than your business logic. Again, not saying it never happens but I’ve rarely seen the kind of microbenchmark this story is about end up correlating with real application performance. I have seen developers get all fired up in some religious war and endanger their entire project trying to see benefits which never materialized, though, a common feature there was this focus on toy benchmarks rather than measuring the whole system or what they could do at the app level if they weren’t supporting some niche framework.
- jesse__ 4y ago
  >> Where I think there’s more of a problem is cultural: [...] there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them. This sounds extremely accurate to me
ex3ndr 4y ago
Express is a slowest solution on the market. Fastify can handle as much as 60k (!) requests per second per core(!): https://www.fastify.io/benchmarks/ https://www.fastify.io/benchmarks/ For example, go can handle about the same amounts (be advised that this tests are for 4 cores, so results have to be divided): https://github.com/smallnest/go-web-framework-benchmark https://github.com/smallnest/go-web-framework-benchmark

geysersam 4y ago

No realistic, decently written, js application would be "orders of magnitude" faster if rewritten in .net.

maccard 4y ago
And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever seen say - js is significantly slower. One example is the techempower benchmarks Fortune section[0]. It's a fairly basic app, but it tests a full stack web app in multiple languages, and it's pretty clear that js is fimrly in the middle of the pack, far behind the compiled options. If you have any sources to the contrary, I'd love to see them. [0] https://www.techempower.com/benchmarks/#section=data-r21&test=fortune https://www.techempower.com/benchmarks/#section=data-r21&tes...
- LunaSea 4y ago
  JavaScript ranks higher than C# in your benchmark.
  - maccard 4y ago
    See my other response here https://news.ycombinator.com/item?id=33224873 https://news.ycombinator.com/item?id=33224873
jesse__ 4y ago
Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.
- azakai 4y ago
  There is often a speedup, but maybe not by orders of magnitude. I've usually seen 2x-3x or so.
- geysersam 4y ago
  Comparing a pure js implemention to code using opengl or webgl, I imagine several orders of magnitude difference is likely. But a decent js implemention of 3D graphics-something would use one of the available tools for such applications. Making the difference considerably smaller. Or is you experience different?
  - jesse__ 4y ago
    I've worked with a couple of the 'decent JS implementation of 3D graphics' libraries and, although they're not all like this, the ones I used were not built by people with experience doing low-level performance work. As such, they made some poor architectural decisions that prevented users of the libraries from doing some very basic optimizations that would have increased perf significantly. The three major blockers I remember were: 1. Render contexts are created on the main thread and the user of the library gets no control over this. This means all driver overhead and library function calls block the main thread, which matters a lot when trying to hit 8ms/frame. 2. Loading textures asynchronously (in another thread, not Javascript async/await) was straight up impossible due to poor architecture. This means app startup was 500ms instead of 5ms. Maybe not a big deal to you, but our use case necessitated quick (a few frames at worst) startup. 3. The renderer used a scene graph, which was hilariously slow to traverse for large numbers of objects. Impossible to optimize by anyone as far as I can tell. Scene graphs just don't work well in JS.

kaba0 4y ago

I’m sorry, but I simply don’t buy that. You either measured something unrelated (e.g. framework), or it was a faulty benchmark for some other reason.

maccard 4y ago
I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21
- LunaSea 4y ago
  JavaScript is ranked 5th on the ranking you linked to. 4 ranks before .Net.
  - maccard 4y ago
    I was hesitant as to how much I should go into this because you get into the semantics of the benchmark but this [0] thread goes into why - that particular implementation doesn't behave the same way as the other implementations, it uses a different db driver that doesn't synchronise, which won't be allowed in the next version of the benchmarks. Techempower publish regular snapshots of their benchmarks at [1], and if you look at any of the snapshots that aren't the last published set where the discrepancy was fixed you'll see that all of the js implementations lag far far behind. [0] https://github.com/TechEmpower/FrameworkBenchmarks/issues/7289 https://github.com/TechEmpower/FrameworkBenchmarks/issues/72... [1] https://tfb-status.techempower.com/ https://tfb-status.techempower.com/
    - xaduha 4y ago
      Are you sure about your conclusion though? Apart from just-js missing in action in last 3 runs, here it's just fine https://www.techempower.com/benchmarks/#section=test&runid=ecfbe3c9-f577-4836-9403-41f9120dfc6e https://www.techempower.com/benchmarks/#section=test&runid=e...

acdha 4y ago

You’re not wrong but I do think it’s important to remember the context: people don’t tend to write math-heavy code in classic JS (there’s a side discussion about WASM now) so relatively few apps bottleneck on CPU - it’s wild when you see people going on about how they need to switch frameworks based on some microbenchmark of request decoding when 99% of their request processing time is some kind of database. I’ve seen more Node apps blow up on RAM usage than CPU because someone thought async would magically make their app faster without asking how much temporary state they were using. Where I think there’s more of a problem is cultural: similarly to Java, there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them.

liuliu 4y ago
"Relatively few apps bottleneck on CPU" is a very 2010 opinion. With fast intranet (100Gbps+) and SSD, running business logic can become the bottleneck in many cases. Unfortunately, I don't have readily available data to back up my claim neither.
- acdha 4y ago
  I’m not saying it can’t happen, just that it’s pretty rare. SSDs are not infinite capacity and 100G networking isn’t common even in data centers - and more to the point, what really matters is latency: how many cycles can your CPU exercise in the time it takes for a round-trip network request is usually orders of magnitude greater than your business logic. Again, not saying it never happens but I’ve rarely seen the kind of microbenchmark this story is about end up correlating with real application performance. I have seen developers get all fired up in some religious war and endanger their entire project trying to see benefits which never materialized, though, a common feature there was this focus on toy benchmarks rather than measuring the whole system or what they could do at the app level if they weren’t supporting some niche framework.
jesse__ 4y ago
>> Where I think there’s more of a problem is cultural: [...] there’s a subset of programmers seemingly dedicated to layering abstractions faster than the JIT developers can optimize them. This sounds extremely accurate to me

ex3ndr 4y ago

Express is a slowest solution on the market. Fastify can handle as much as 60k (!) requests per second per core(!): https://www.fastify.io/benchmarks/ https://www.fastify.io/benchmarks/ For example, go can handle about the same amounts (be advised that this tests are for 4 cores, so results have to be divided): https://github.com/smallnest/go-web-framework-benchmark https://github.com/smallnest/go-web-framework-benchmark