Consider remove aggressive inlining for small method

[YohDeadfall]

The code can be simplified by avoiding MethodImpl with AggressiveInlining at least for simple methods since the JIT compiler is smart enough to do that automatically at least for .NET/.NET Core (has no idea about .NET Framework and cannot check it). There's a rule for small methods which IL size is lower or equal to 32 bytes, and attributed methods I checked just reroute execution. There are additional rules on flow graphs, but again, these methods are very simple and should be automatically inlined.

[kekyo]

Thanks for the suggestions! 😄 I tend to write this attribute and it has affected FlashCap as well. As you pointed out, I knew that JIT automatically optimizes for small method bodies. And likewise, I don't know exactly how it works in the .NET Framework CLR.

On the other hand, I am not comfortable with the application of a lot of attributes whose effects are not concrete. I would be willing to consider removing attributes in a positive way.

---

The following is really based on my personal imagination and thoughts and may have nothing to do with this issue.

The reason why I persistently apply this attribute is because (which has nothing to do with FlashCap) in one of my projects, IL2C, I had the intention of using this attribute as a apply to give the output C code inline as well (not yet realized, but not difficult to do so).

This means, of course, that it is hard to guess how this attribute will be evaluated by the .NET runtime. .NET runtime nowadays may refer to CoreCLR, but not so long ago (really not so long ago ! :) , mono was still in use and there were various attempts to re-implement CLR. Since I am one of those people, I would unintentionally implement the CoreCLR in such a way that it is neutral and not adapted to the convenience of CoreCLR.