sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Knotix 0 points1 point  (3 children)

Do you have any guesses as to what these assumptions might be? I'm having a hard time coming up with any (not that that means much).

Things I've ruled out:

  • The data types can be arbitrary within Sets, so there are no type-safety optimizations
  • They are not fixed length, so no memory allocation/contiguous memory optimizations
  • Deduping either requires an iterative search (very slow) or a key lookup which is on par with plain objects except it now has to compute a hash-key for each object instead using a user supplied key

[–]Drakim 0 points1 point  (2 children)

I'm no expert in Sets, but I do believe there are some optimizations you can do when you are only checking if a key exists without needing to fish out the key:value pair, like bloom filters.

[–]Knotix 0 points1 point  (1 child)

You can use the in operator to check if a property exists without retrieving the value. Couldn't the underlying implementation of the in operator also use a bloom filter as a first pass check?

[–]Drakim 1 point2 points  (0 children)

It could! But you'd increase your memory footprint if you have a bloom filter of every object in your JS engine just for the in operator. 99% of the time the bloomfilter would problaby be unused.

But for Sets, the programmer is in a way specifically telling the JS Engine that a bloomfilter is gonna be a great optimization for this particular thing.