Is JavaScript Spread a Performance Killer? Quick Fix

(I said destructuring when what I'm really doing is spreading, same performance impacts apply regardless of the terminology.)

👉 What's my theme? Night Wolf [black]
👉 What's that font? Operator Mono

00:00 Introduction
00:35 Object speading performance
05:45 Array speading performance
08:06 Why do we do this?
09:10 Outroduction

Thank you for watching this video, click the "SUBSCRIBE" button to stay connected with this channel.

#javascript #quickFix

[lynn_phoenix]

For a real world improvement, this was the difference of a search endpoint taking 1100ms vs 200ms. The original developer preferred DX with expressive code over user affecting performance and it caused Core Web Vital issues.

[ZakiWasik]

This is really interesting. I've been doing spread destructuring simply out of habits acquired from using Redux. But I guess I have to rethink that when using reduce.

[henrmota]

Jack, I think it would be interesting to make a video on how to measure the performance of functions and how to measure that performance. Thanks for your videos.

[ddoice]

This is why ended up using ramda, it allows you to keep the functional syntax with great performance.

On a brute force code I needed all the permutations of combinations of words extracted from paragraphs (near 1.5M), the code using reduce will take 4 hours to calculate all, with ramda was 5 secs.

[floofynuggets]

This is a great tip, Jack! I've also implemented this in performance-sensitive situations. However, I don't always apply this advice because of the no-param-reassign eslint rule which I usually have enabled in my projects. This rule helps avoid mutating object references passed into a function.

I think I'd add one point to Jack's video here: this performance-boosting trick has no downsides _because_ the lookup is initialized with {}, and not an existing object reference. If you're in this situation, only _then_ is it permissible to apply this approach and ignore the rule.

Cheers!

[HeinekenLasse]

Wow I always thought that background was real haha

[KayB]

This is amazing, More efficiency tips like this would be awesome short videos to share with friends.

[JulioDx]

I had no idea about this performance hit with destructuring. Thanks for sharing.

[AbdelhameedG]

Thanks Jack, That was enlighting, Would love to see more videos about performance from you.

[DanielTateNZ]

This answers the questions I had on your other reduce video. Thanks!

[purswanitarun]

Your voice and way of explaining makes me want to get up early and always keep learning.
Thank you :)

[sagarreddy]

Awesome content jack, thanks. Waiting for your js objects details series

[mammothoff]

I always destructture with spread, but now I'll think twice before using spread, thanks 👍🏻

[codezero]

Yes, I have gotten burned using an assign function in a reduce. The spread operator may seem more functional, but “mutating” the accumulator by setting the key is much more efficient.

[jrs_devs]

Perfecto!, just corrected a couple of pieces of code with this smart fix. Thank you Jack!

[Sashankyt]

I would have never done that spread but it was insightful. Thank You.

[_erfanm]

Right, but I didn't see anything about destructuring (the title) in the video.

It was about the performance effect of using the spread operator for returning a new object on every iteration.

[mohammadmahdifarnia]

Immutability kills performance & blows up memory.

react-table had this issue (primegen has a video on this)

Great video👍

[adamlerman]

Thanks as always for a great video Jack!

[ShaharHarshuv]

I think mutating the object you're creating still abides functional programming principles since you're not mutating the function arguments, so the function is still pure. I think it's ok that the reducer's callback is not pure since it's used once and in place