Introduce set with custom equals and getHashCode

[amcasey]

I got tired of not having custom hash sets in JS so I made a naive one.

Not using linear search to de-dup rename locations cuts search for locations of Type from 1750 ms to 1450 ms.

I plan to use this in a bunch of other places in my FAR cleanup.

TODO: this is the simplest possible implementation
TODO: these were the consumers that I'd encountered recently

[sandersn]

This seems like a reasonable thing to have, although I'm tempted to say it should be in src/server since it's used only there. Probably having it in a central place is more valuable though.

[andrewbranch]

Do you have a sense of how often you expect entries in the set to share a hash? If best practice is for hashes to be unique whenever possible (and it may not be, I don’t know), I wonder if it would be better to let the underlying map values be TElement | TElement[], promoting to an array only once two entries share a hash. That could make for a lot fewer array allocations for large sets with unique hashes, at the expense of probing the array-likeness of the values, lack of support for TElement itself being array-like, and polymorphism when some entries do share a hash. FWIW I tried this with the ExportInfoMap which is a multimap where you have multiple values when a symbol is re-exported, so in practice that meant that a majority of values were singles but arrays were not uncommon. I couldn’t measure any difference between the always-arrays and arrays-when-needed approaches, so I went with the simpler always-arrays approach like you have here. But I’m curious if you’ve thought about or tried the same thing.

[amcasey]

@andrewbranch Generally speaking, I'd expect collisions to be pretty common in a hashset, but I have no particular objection to dynamically promoting values to arrays - this is just the simplest code that solved my problem.

Any thoughts on @sandersn's suggestion of clearly separating this from Set<T>?

[andrewbranch]

Any thoughts on @sandersn's suggestion of clearly separating this from Set<T>?

Personally, I don’t think it’s much of an issue since new Set() ought to be the obvious default to reach for when creating a Set, and the getHashCode and equals parameters are required in your API, so it becomes obvious quickly that you’re not creating a native Set.

[amcasey]

Re-opening to see if that causes it to pick up the additional commits I pushed.