Open ElektroKill opened 4 years ago
Enum
s are indeed numbers, but not always of type Int32
.
If they are not used in reflection, it is even possible to turn them into numbers by changing even method signatures, if we take it aggressively enough.
When Enum.ToString
is to be called, it is possible to replace it with a function that using jump table, dictionary lookup, sequential direct compares or combination of the above to convert numbers to literal strings.
Eliminating Enum
s could help protection a little bit.
@wmjordan Didn’t think about the handling of ToString since I thought it could just get excluded. I terms of performance I have done some experiments and using pure numbers can be slightly faster then enums. This is however only present when calling methods. I think this optimization/protection shouldn’t be that hard to implement.
It is interesting that pure numbers could perform faster than enums. I have programmed quite a few IL related stuff and I always use numbers instead when enums are in place of any method parameters. Actually it is how the compiler does when it loads an enum value--it just loads a number.
I just thought that actually there's no enum for the CLR. Enums are enums only when their methods (ToString
, etc.), are called. And quite unfortunately, the implementation of ToString
in .NET Framework is not so good and it can be optimized, since we can avoid reflections and type comparisons and conversions.
That shouldn't be the case. Enums and what ever type they are implemented with should perform exactly the same. Enums don't actually restrict what values can be used. Every value that is covered by the type the enum uses may be stored in a field of the enum type. I really wonder where the different should come from.
Accessing the ToString
is a whole different beast. This relies on the private Type.GetEnumData
Method that discovers all the fields of an enum by reflection every time ToString
is called for a enum. That is something that could be optimized in case it's safely discovered. A static method that just returns the original names of the fields in the enum would do the job here. Just need to be careful with the FlagsAttribute
Removal of const has already been posted in #91 and #53. It is really a common consideration of protection.
As @mkaring has stated in #53 (Something like this will be added. Stripping unused internal members, types and constants.). This request should be naturally get handled at the same time.
I also vote for Automatic class sealing. It should not be difficult to implement but it really helps improvement of performance.
- Removal of unnecessary attributes
Another candidate of removal may be: System.Diagnostics.CodeAnalysis.SuppressMessage
.
Hello, I saw that the 2.0 branch will include protections that aim to optimize the protected code. I have recently come up with 4 more optimization ideas that are not listed in the 2.0 milestone.
Here they are: