ImmutableHashSet<T>.SetEquals always creates a new HashSet<T>

[sharwell]

The following HashSet<T> calculation could be avoided by using other.WithComparer(origin.KeyComparer) in the specific case where other is already an ImmutableHashSet<T>. It might also be avoidable in the case where other is already a HashSet<T> with an appropriate comparer.

Note that in addition to the overhead of performing these checks at runtime, there may be overhead added by the fact that ImmutableHashSet<T> has a slower enumerator than HashSet<T>, and the newly allocated set is immediately enumerated.

runtime/src/libraries/System.Collections.Immutable/src/System/Collections/Immutable/ImmutableHashSet_1.cs

Line 758 in 7edfbc7

var otherSet = new HashSet<T>(other, origin.EqualityComparer);

Tagging subscribers to this area: @dotnet/area-system-collections
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The following HashSet<T> calculation could be avoided by using other.WithComparer(origin.KeyComparer) in the specific case where other is already an ImmutableHashSet<T>. It might also be avoidable in the case where other is already a HashSet<T> with an appropriate comparer.

Note that in addition to the overhead of performing these checks at runtime, there may be overhead added by the fact that ImmutableHashSet<T> has a slower enumerator than HashSet<T>, and the newly allocated set is immediately enumerated.

runtime/src/libraries/System.Collections.Immutable/src/System/Collections/Immutable/ImmutableHashSet_1.cs

Line 758 in 7edfbc7

var otherSet = new HashSet<T>(other, origin.EqualityComparer);

Author:	sharwell
Assignees:	-
Labels:	area-System.Collections
Milestone:	-

[MadL1me]

@eiriktsarpalis can I work on this? Looks good as a starting point for runtime contributions

[eiriktsarpalis]

Sure, feel free to submit a PR.

[MadL1me]

@sharwell aren't you solved the problem with dotnet/roslyn#69673 PR?

[manandre]

The issue is still not fixed.
dotnet/roslyn#69673 only implements a local workaround until it is correctly fixed here in the runtime.
@MadL1me Are you still willing to work on this?