Using Sets in ES6 to produce lists of unique objects is faster than using arrays, and less error prone than using objects. In this lesson, we explore the pitfalls of the object approach and the speed implications of the array approach. We will then instrument the array approach and the set approach to measure the number of operations each approach performs, and it's implications on program speed.
Subjectively the more important thing here might be the ease of adding decorators in ES6. Great video.
What if using console.time to test looks more accurate?
Hi Darren,
Thanks for the feedback! Console.time would be good too. In this specific case though, the actual run time difference is negligible because 1.5 million operations is still decently fast, and modern JS engines do tricky things to speed up things further for simple loops. In reality, Set usage is likely more complicated than simple iteration.
My intention was to show how quickly the number of operations grows for O(n^2) algos vs. O(n) to give the viewer a more intuitive sense of the numbers, and less about the actual performance of the contrived example.
Hi Mike,
So do you recommend to use set method store data instead of using array? I found set api can easier convert to array via Array.from method and it has its own forEach method for looping. Or it depends on different data structures. Thanks for response.
Sets can only represent unique sets of elements, and compared to Arrays, have a smaller, less powerful set of APIs. I typically only Sets when I have that unique requirement.
Okay Mike, Thank you for explanation. Very helpful.
Hey Mike, Thanks for the Video. Shouldn't we use (setOps = setOps + this.size) to compute the setOps in has() as internally set might be iterating over all the elements to find if a value already exist in set or not?
Hey Mike, Thanks for the Video. Shouldn't we use (setOps = setOps + this.size) to compute the setOps in has() as internally set might be iterating over all the elements to find if a value already exist in set or not?
Good question! Set (and Map) has been specifically designed to have O(1) lookups and does not need to iterate over all its elements to do so.
Hey Mike, Thanks for the Video. Shouldn't we use (setOps = setOps + this.size) to compute the setOps in has() as internally set might be iterating over all the elements to find if a value already exist in set or not?
Good question! Set (and Map) has been specifically designed to have O(1) lookups and does not need to iterate over all its elements to do so.
Found algorithm of has in ES6 doc file. https://www.ecma-international.org/ecma-262/6.0/#sec-set.prototype.has . I hope I am looking in the right direction.
Found algorithm of has in ES6 doc file. https://www.ecma-international.org/ecma-262/6.0/#sec-set.prototype.has . I hope I am looking in the right direction.
Almost :-). See here: https://www.ecma-international.org/ecma-262/6.0/ where it says:
Set objects must be implemented using either hash tables or other mechanisms that, on average, provide access times that are sublinear on the number of elements in the collection. The data structures used in this Set objects specification is only intended to describe the required observable semantics of Set objects. It is not intended to be a viable implementation model.
“Hash tables” and “sublinear access” are the key words there.
Got It! :-). Thanks for your quick revert.
This was awesome
! I like you explained it!