use empirically found threshold to speed up issubset by creating Set …

[twistedcubic]

This plot shows the timing comparison between the hash-based O(m + n) issubset, vs the double for-loop O(mn) approach, where m = length(n) and n = length(m).

This reveals a threshold size at which the constant-time lookup of the hashset overtakes the overhead imposed by creating that set.

The x-axis shows the number of elements in the collection to check membership against (the right hand side). The y-axis shows time in seconds.

It shows the necessity to use hashing for efficient performance. This addresses #24624.

Various timing experiments reveal the threshold size to be ~70. As shown:

[JeffBezanson]

It occurred to me that this should probably use isa(r, AbstractSet) (there are other kinds of sets, all of which should probably have efficient in methods).

[twistedcubic]

Will do. I just learned that IntSet is implemented as a bit string.

[nalimilan]

Thanks for doing this benchmarking. Does the threshold depend on the element type? I would imagine that's the case. Could you document which type you used here? I guess Int? Complex types like String would likely benefit even more from using a Dict, meaning an even lower threshold could be chosen.

[twistedcubic]

@nalimilan the benchmarks are done with strings, in particular strings of integers, e.g. "1", "2", ... . I will repeat the benchmark for different types to get a general feel, I agree the timing most likely depends on the type.

I can see the constant time lookup can benefit complex types like Strings even more, though in that case I believe constructing Sets for Strings also takes longer, since Int can be its own hash (I will double check with the source).

[JeffBezanson]

We don't hash Ints to themselves, but computing that is still much faster than hashing a String.

[nalimilan]

OK. The length of the string will probably matter a lot too.