The problem is boxing. It's an act of turning value type into object, which might, or might not be unnecessary.
The way Dictionarycompares keys, is essentially, that it will use EqualComparer<T>.Default, and call GetHashCode() to find correct bucket, and Equals to compare if there's any value in the bucket that is equal tot he one we're looking for.
The good thing is this: .NET framework has good optimizations, which avoid boxing in the case of "Enum integers". See CreateComparer(). It's highly unlikely that you will see any difference here, between integers and enums, as keys.
To note here: this is not an easy act, in fact, if you dig in deep, you'll come to conclusion that quarter of this battle is implemented through CLR "hacks". As seen here:
static internal int UnsafeEnumCast<T>(T val) where T : struct
{
// should be return (int) val; but C# does not allow, runtime
// does this magically
// See getILIntrinsicImplementation for how this happens.
throw new InvalidOperationException();
}
It could be definitely easier if generics had Enum constraint, and perhaps even something a long of the lines UnsafeEnumCast<T>(T val) where T : Enum->Integer, but well... they don't.
You might be wondering, what exactly is going on in getILIntrinsicImplementation for that EnumCast? I wonder too. Not exactly sure as of this right moment how to check it. It's replaced on run-time with specific IL code I believe?!
MONO
Now, answer to your question: yes you're right. Enum as a key on Mono, will be slower in a tight loop. It's because Mono does boxing on Enums, as far I can see. You can check out EnumIntEqualityComparer, as you can see, it calls Array.UnsafeMov that basically casts a type of T into integer, through boxing: (int)(object) instance;. That's the "classical" limitation of generics, and there is no nice solution for this problem.
Solution 1
Implement an EqualityComparer<MyEnum> for your concrete Enum. This will avoid all the casting.
public struct MyEnumCOmparer : IEqualityComparer<MyEnum>
{
public bool Equals(MyEnum x, MyEnum y)
{
return x == y;
}
public int GetHashCode(MyEnum obj)
{
// you need to do some thinking here,
return (int)obj;
}
}
All you need to do then, is pass it to your Dictionary:
new Dictionary<MyEnum, int>(new MyEnumComparer());
It works, it gives you the same performance as it is with integers, and avoids boxing issues. The problem is though, this is not generic and writing this for each Enum can feel stupid.
Solution 2
Writing a generic Enum comparer, and using few tricks that avoids unboxing. I wrote this with a little help from here,
// todo; check if your TEnum is enum && typeCode == TypeCode.Int
struct FastEnumIntEqualityComparer<TEnum> : IEqualityComparer<TEnum>
where TEnum : struct
{
static class BoxAvoidance
{
static readonly Func<TEnum, int> _wrapper;
public static int ToInt(TEnum enu)
{
return _wrapper(enu);
}
static BoxAvoidance()
{
var p = Expression.Parameter(typeof(TEnum), null);
var c = Expression.ConvertChecked(p, typeof(int));
_wrapper = Expression.Lambda<Func<TEnum, int>>(c, p).Compile();
}
}
public bool Equals(TEnum firstEnum, TEnum secondEnum)
{
return BoxAvoidance.ToInt(firstEnum) ==
BoxAvoidance.ToInt(secondEnum);
}
public int GetHashCode(TEnum firstEnum)
{
return BoxAvoidance.ToInt(firstEnum);
}
}
Solution 3
Now, there's a little problem with the solution#2, as Expression.Compile() is not that famous on iOS(no runtime code generation), and some mono versions don't have ?? Expression.Compile ?? (not sure).
You can write simple IL code that will take care of the enum conversion, and compile it.
.assembly extern mscorlib
{
.ver 0:0:0:0
}
.assembly 'enum2int'
{
.hash algorithm 0x00008004
.ver 0:0:0:0
}
.class public auto ansi beforefieldinit EnumInt32ToInt
extends [mscorlib]System.Object
{
.method public hidebysig static int32 Convert<valuetype
.ctor ([mscorlib]System.ValueType) TEnum>(!!TEnum 'value') cil managed
{
.maxstack 8
IL_0000: ldarg.0
IL_000b: ret
}
}
In order to compile it into an assembly, you have to call:
ilasm enum2int.il /dll where enum2int.il is the text file containing IL.
You can now reference the given assembly(enum2int.dll) and call the static method, as such:
struct FastEnumIntEqualityComparer<TEnum> : IEqualityComparer<TEnum>
where TEnum : struct
{
int ToInt(TEnum en)
{
return EnumInt32ToInt.Convert(en);
}
public bool Equals(TEnum firstEnum, TEnum secondEnum)
{
return ToInt(firstEnum) == ToInt(secondEnum);
}
public int GetHashCode(TEnum firstEnum)
{
return ToInt(firstEnum);
}
}
It might seem to be killer code, but it avoids boxing, and it should give you better berformance on Mono.
enumhere. It will have identical performance implications to using an integer (assuming it's backed by one, which it will be by default). – SounderEnumand not an integer as a key for a dictionary. – SounderGetHashCodeon an enum allocate memory? – PuissantEnumis nothing but compile time wrapping for an integer, you have every reason to doubt it. The issue is almost certainly with your testing, rather than with the code. – SounderIDictionary<S,T>whereSis an enum type is that it's kind of difficult to restrict a generic type to a enum. If you have only a handful of enums to worry about, it might be worth your time to create a (bunch of)MyEnumDictionary<T> : IDictionary<MyEnum,T>for each enum. – StefanstefanacComparer.cs, its implementation ofComparer<T>.Defaultis quite a poor one. – Ingurgitate