Ask HN: What are the hidden performance tricks for JavaScript?
16 comments
A few general suggestions:
• Learn Rust! When I learned how memory worked, it made me a much better JS dev.
• Check out Casey Muratori's courses on performance. Some are free on YouTube.
• Start from scratch with a data-oriented approach. What bits do you need to move around, and why? What's the best way to store and shape those bits?
• Can/should you use WASM instead?
• Learn Rust! When I learned how memory worked, it made me a much better JS dev.
• Check out Casey Muratori's courses on performance. Some are free on YouTube.
• Start from scratch with a data-oriented approach. What bits do you need to move around, and why? What's the best way to store and shape those bits?
• Can/should you use WASM instead?
If working with number arrays using Float32Array can provide significant improvements to performance.
Never use .forEach(), always use a for loop. Same applies to methods like .map().
Some calculations are just much more expensive to do than others. Exponentiation for example is much more expensive than multiplication. You want to write your code in a way that not only considers the total number of operations, but also minimises expensive operations.
Caching can help if you're doing repetitive computations.
If you're absolutely pushing performance to the max you will probably want to look at doing some clever stuff with WebGL2, WASM or Web Workers. Wherever you can avoid this though I would recommend it because it will make your code much more complicated and won't even necessarily out perform because of overheads.
Edit: Also check out this guy on YT, https://www.youtube.com/watch?v=WLwTlC1R2sY He does some really interesting deep dives into JS performance.
Never use .forEach(), always use a for loop. Same applies to methods like .map().
Some calculations are just much more expensive to do than others. Exponentiation for example is much more expensive than multiplication. You want to write your code in a way that not only considers the total number of operations, but also minimises expensive operations.
Caching can help if you're doing repetitive computations.
If you're absolutely pushing performance to the max you will probably want to look at doing some clever stuff with WebGL2, WASM or Web Workers. Wherever you can avoid this though I would recommend it because it will make your code much more complicated and won't even necessarily out perform because of overheads.
Edit: Also check out this guy on YT, https://www.youtube.com/watch?v=WLwTlC1R2sY He does some really interesting deep dives into JS performance.
> If working with number arrays using Float32Array can provide significant improvements to performance.
Do you mean TypedArray? [0]
> Never use .forEach(), always use a for loop. Same applies to methods like .map().
I just found it out yesterday [1]. It's a nice trick. I already changed all forEach (even tho it maked my eyes a little bit wet).
> some clever stuff with WebGL2, WASM or Web Workers
I already use Web Workers with async calls to divide main task into smaller pieces and not to block main render. But I am pretty new to this concept so I don't grasp fully what is the overhead of using this method.
Thank you for the video - will check it now.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] https://leanylabs.com/blog/js-forEach-map-reduce-vs-for-for_...
Do you mean TypedArray? [0]
> Never use .forEach(), always use a for loop. Same applies to methods like .map().
I just found it out yesterday [1]. It's a nice trick. I already changed all forEach (even tho it maked my eyes a little bit wet).
> some clever stuff with WebGL2, WASM or Web Workers
I already use Web Workers with async calls to divide main task into smaller pieces and not to block main render. But I am pretty new to this concept so I don't grasp fully what is the overhead of using this method.
Thank you for the video - will check it now.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] https://leanylabs.com/blog/js-forEach-map-reduce-vs-for-for_...
> Do you mean TypedArray? [0]
Yes, generally you'll want Float32Array, but I guess which TypedArray you'll want to use in your code use will depend on use.
> I already use Web Workers with async calls to divide main task into smaller pieces and not to block main render. But I am pretty new to this concept so I don't grasp fully what is the overhead of using this method.
If you can you'll want to use a "transferable object" to reduce overheads when passing data into worker thread, https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
If you're using Web Workers this is a great video to watch and it discusses "transferable objects" around the 7 minute mark, https://www.youtube.com/watch?v=pQPqhZRUz3U
The other thing I forgot to mention was to avoid using async/await wherever possible. I'm guessing you're not using it unnecessarily anyway, but it will add a significant overhead to your method calls if you are.
Yes, generally you'll want Float32Array, but I guess which TypedArray you'll want to use in your code use will depend on use.
> I already use Web Workers with async calls to divide main task into smaller pieces and not to block main render. But I am pretty new to this concept so I don't grasp fully what is the overhead of using this method.
If you can you'll want to use a "transferable object" to reduce overheads when passing data into worker thread, https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
If you're using Web Workers this is a great video to watch and it discusses "transferable objects" around the 7 minute mark, https://www.youtube.com/watch?v=pQPqhZRUz3U
The other thing I forgot to mention was to avoid using async/await wherever possible. I'm guessing you're not using it unnecessarily anyway, but it will add a significant overhead to your method calls if you are.
amazing video! Thank you very much
What is the actual operation you're trying to optimize? What does the code need to do?
I have a large SVG calculation occurring with every rendering. Essentially, the code generates millions of SVG polylines based on a pseudo-random generator, then needs to stringify them and post them inside the canvas.
What are the constraints? Does it have to go through an SVG intermediary (as opposed to raw pixel math, for example)? Does the canvas have to be responsive? Can you use GPU calculations?
I don't know what you've tried already, but typically SVGs are very slow to work with. If you're drawing to a canvas anyway, you should see if you can skip the XML altogether and do the math to draw directly to the canvas (or use a helper lib like Konva or Pixi or D3 etc.). Can any of the line generation and stringification be offloaded to WASM, which can often be several times faster than JS? Can any of it be offloaded to a GPU, depending on which platforms you need to support?
I'm still not sure what the actual use case is for a bunch of random polylines (is it a visualization of something? a scientific calculation? background graphics?). If they don't represent any actual data and are just a graphical nicety, can you fake them somehow (bitmap sprites with different transformations)? And does it have to happen client-side in real time (can you just prerender it?)?
I don't know what you've tried already, but typically SVGs are very slow to work with. If you're drawing to a canvas anyway, you should see if you can skip the XML altogether and do the math to draw directly to the canvas (or use a helper lib like Konva or Pixi or D3 etc.). Can any of the line generation and stringification be offloaded to WASM, which can often be several times faster than JS? Can any of it be offloaded to a GPU, depending on which platforms you need to support?
I'm still not sure what the actual use case is for a bunch of random polylines (is it a visualization of something? a scientific calculation? background graphics?). If they don't represent any actual data and are just a graphical nicety, can you fake them somehow (bitmap sprites with different transformations)? And does it have to happen client-side in real time (can you just prerender it?)?
This was attempt to research the fastest possible approach to a JavaScript GUI in the browser.
https://github.com/prettydiff/wisdom/blob/master/performance...
The techniques mentioned are stupid fast to the fewest milliseconds, but most JavaScript developers find this incredibly unpopular.
https://github.com/prettydiff/wisdom/blob/master/performance...
The techniques mentioned are stupid fast to the fewest milliseconds, but most JavaScript developers find this incredibly unpopular.
you can "force" integer arithmetic with bit or (example your_float|0), this helps the JavaScript runtime to optimise calls and use (faster) int arithmetic. (https://stackoverflow.com/questions/23436159/how-bitwise-ope...)
always remember the fastest code is the code that is not executed at runtime.
always remember the fastest code is the code that is not executed at runtime.
Don’t use the strict equality operator if type inequality should short circuit to false. It is 30-70% faster to check for equality of the result of typeof, and only when true to check value equality.
This makes no sense to me, since checking type is supposedly the first step of each equality operator’s algorithm, but this is the result JSBench keeps returning me.
This makes no sense to me, since checking type is supposedly the first step of each equality operator’s algorithm, but this is the result JSBench keeps returning me.
I haven't used them much, but I would check out typed arrays:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
if you're just trying to initialize a new Array, you can just hardcode it and get much better performance.
https://www.measurethat.net/Benchmarks/Show/29982/0/hardcode...
This isn't necesarrily unknown, but knowing that there's a cost associated with promises and async/await will get you pretty far in terms of performance. I remember the idea first clicking when I watched this : https://www.youtube.com/watch?v=SMBvjmeOotA
This isn't necesarrily unknown, but knowing that there's a cost associated with promises and async/await will get you pretty far in terms of performance. I remember the idea first clicking when I watched this : https://www.youtube.com/watch?v=SMBvjmeOotA
It's an interesting trick with the hardcoded array! Thanks.
The video you posted is a bit chaotic, so I don't really want to watch 1.5 hours just to get something that could be summarized in one line. But anyway... I understand the downsides of promises calls, but there are also advantages, such as not blocking page rendering, which I heavily rely on.
The video you posted is a bit chaotic, so I don't really want to watch 1.5 hours just to get something that could be summarized in one line. But anyway... I understand the downsides of promises calls, but there are also advantages, such as not blocking page rendering, which I heavily rely on.
Typed arrays are fast, for(let i = O; i < max; i++) loops are fast. But also, what kind of tool are you making where you need every milliseconds but also need to use JS?
Binge on https://v8.dev/blog
Use chrome profiler
Use chrome profiler
One discovery I've made is that using new Array is significantly faster than Array.from or push()[0].
Could you share any similar insights or lesser-known performance optimizations you've come across?
[0] https://www.measurethat.net/Benchmarks/ShowResult/506720