mkaring
Potential optimization ideas
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:
- Removal of unused const fields. Since the compiler already inlines the const fields it would make sense to remove internal or private const fields.
- Unnecessary Enum removal. The runtime handles enums just like regular int32 values so it would be possible to remove some of the internal and private enums that are not needed. This would decrease file size. However, this needs some analysis of the code to make sure that the enums are never used.
- Removal of unnecessary attributes. Some attributes are added by the compiler but are no needed for runtime. An example of such an attribute is the "CompilerGenerated" attribute. from what I know it has no effect on the runtime code. Removal of attributes such as "CompilerGenerated" can also throw off some decompilers.
- Automatic class sealing. The JIT compiler treats sealed classes slightly differently which may lead to increased performance in some cases.
Enums 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 Enums 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.