4 ms·

Honest question and a bit of a side-note, is javascript actually fast? Because in my experience it's still pretty slow, it's just relatively faster than it was.

Honest question and a bit of a side-note, is javascript actually fast? Because in my experience it's still pretty slow, it's just relatively faster than it was. For example I remember doing a Mandelbrot set generator in js about 3 years ago and it was a lot slower than C#. I'm talking orders of magnitude, methods that took 10 ms in C# would take 1000 ms in js. But worse than that it hit incredible performance problems when I had an array of more than 10,000 items and tried to use push/unshift or a shift/pop. I'm no language expert, and I never really dug into why as it was just for fun. Be interested to hear other people's perspective or a more technical explanation. I'm not really interested in those 'we tested these simple method speed' comparisions, I'm more interested in practical experiences. EDIT: Regarding tooling, I'm presently optimizing js in a client's site and the profiling in dev tools is still basic compared to professional tools in C# for example, so this guy needs to expand his experience if he thinks DevTools is 'good'.

lojack 11y ago
It's fast for IO bound applications because of its natural asynchronousity. For CPU bound applications, it's moderately competitive with other interpreted languages, not particularly fast, but acceptable for a lot of things.
xiaoma 11y ago
It's fast compared to Ruby or Python, but slow compared to Java or C#. You really wouldn't want to do number crunching in it anyway, since it only has one type of Number—floats.
coldtea 11y ago
It's much faster than Python, Ruby, PHP scripting languages in microbenchmarks testing just the language's features (no C libs). It can get to 1.5x / 2x slower than C. You can get whole games like Quake to compile and run in real time in JS and in high resolution, so the Mandelbrot set should pose no issue at all. You need to take care to work with the JIT though, not sabotage it. Perhaps the code went in an non-optimal way? For Mandelbrot, eg. instead of an array of tons of objects you could allocate memory in a buffer and have JS manage it.
- mattmanser 11y ago
  Quake was released in 1996, so what's so amazing about that? Because of Moore's law a 20 year old game running in IE6's javascript engine would probably be fast enough. The equivalent Ruby, Python or PHP could easily run Quake on today's hardware. Also, what do you mean by 'much'. Like orders of magnitude or 30%? Microbenchmarks are fairly useless.
  - coldtea 11y ago
    >Quake was released in 1996, so what's so amazing about that? I didn't say Quake 1. Actually all of Quake 1-4 has been ported to run under JS/WebGL. Besides, it's still amazing given that the rendering happens in high resolutions and gets good refresh rates. Moore's law or not, Python and Ruby can't pull this off with the same speed. >Also, what do you mean by 'much'. Like orders of magnitude or 30%? For things that test the raw language (e.g. its interpreter and implementation, instead of directly calling to some C helper that does everything like e.g. Math.cos would do) it's usually an order of magnitude.
ericelliott 11y ago
Try restricting yourself to the ASM.js subset of JavaScript and see how things work out for you. JS is capable of supporting Unreal Engine 4 games in-browser by compiling to ASM.js. Of course JavaScript's dynamic features and garbage collector are going to have an impact on perf. See if you can sidestep them to improve on your results. Another issue you may look at is that we don't have standardized support for SIMD yet (but it's coming soon). SIMD would help a lot for the Mandlebrot set. Try with one of the experimental SIMD implementations and see how that works for you. You're right that I'm not familiar with the profiling features for C# tools, but DevTools' profile recording, flamegraphs, and memory profiling features are better than the tools I used in C++ and Java. =)

lojack 11y ago

It's fast for IO bound applications because of its natural asynchronousity. For CPU bound applications, it's moderately competitive with other interpreted languages, not particularly fast, but acceptable for a lot of things.

xiaoma 11y ago

It's fast compared to Ruby or Python, but slow compared to Java or C#. You really wouldn't want to do number crunching in it anyway, since it only has one type of Number—floats.

coldtea 11y ago

It's much faster than Python, Ruby, PHP scripting languages in microbenchmarks testing just the language's features (no C libs). It can get to 1.5x / 2x slower than C. You can get whole games like Quake to compile and run in real time in JS and in high resolution, so the Mandelbrot set should pose no issue at all. You need to take care to work with the JIT though, not sabotage it. Perhaps the code went in an non-optimal way? For Mandelbrot, eg. instead of an array of tons of objects you could allocate memory in a buffer and have JS manage it.

mattmanser 11y ago
Quake was released in 1996, so what's so amazing about that? Because of Moore's law a 20 year old game running in IE6's javascript engine would probably be fast enough. The equivalent Ruby, Python or PHP could easily run Quake on today's hardware. Also, what do you mean by 'much'. Like orders of magnitude or 30%? Microbenchmarks are fairly useless.
- coldtea 11y ago
  >Quake was released in 1996, so what's so amazing about that? I didn't say Quake 1. Actually all of Quake 1-4 has been ported to run under JS/WebGL. Besides, it's still amazing given that the rendering happens in high resolutions and gets good refresh rates. Moore's law or not, Python and Ruby can't pull this off with the same speed. >Also, what do you mean by 'much'. Like orders of magnitude or 30%? For things that test the raw language (e.g. its interpreter and implementation, instead of directly calling to some C helper that does everything like e.g. Math.cos would do) it's usually an order of magnitude.

ericelliott 11y ago

Try restricting yourself to the ASM.js subset of JavaScript and see how things work out for you. JS is capable of supporting Unreal Engine 4 games in-browser by compiling to ASM.js. Of course JavaScript's dynamic features and garbage collector are going to have an impact on perf. See if you can sidestep them to improve on your results. Another issue you may look at is that we don't have standardized support for SIMD yet (but it's coming soon). SIMD would help a lot for the Mandlebrot set. Try with one of the experimental SIMD implementations and see how that works for you. You're right that I'm not familiar with the profiling features for C# tools, but DevTools' profile recording, flamegraphs, and memory profiling features are better than the tools I used in C++ and Java. =)