2

From this answer I've learned that it is possible to strongly suggest inlining in C# as follows:

using System.Runtime.CompilerServices; 

[MethodImpl(MethodImplOptions.AggressiveInlining)]
bool MyCondition() { return someObject != null && someObject.Count > 2; }

In a current project we use statemachines as defined by the Appccelerate StateMachine framework, which results in sequences like the following (which in our project are much longer):

fsm.In(States.A)
   .On(Events.B)
      .If(arguments => false).Goto(States.B1)
      .If(() => someVariable && somethingElse == false).Goto(States.B3);
      .If(MyCondition).Goto(States.B2)

In order to simplify these structures I would like to separate the lambda expressions (or Action delegates) into helper methods (i.e. the last statement). Reasons for doing so is that with proper method names it would increase readability of the code, and secondly when autogenerating documentation it will use the method name instead of the non-intuitive [anonymous] text.

The question however, is whether it is any point in using AggressiveInlining or will simple lambda expressions involving upto 4 variables with simple comparison operators be automatically inlined by JIT/compiler?

My gut feeling is to inline these methods, as I believe the different parts of the statemachine will get a lot of hits, and thusly to reduce method calling would be a benefit. But then again how smart is JIT/compiler to automagically do this?

Community
  • 1
  • 1
holroy
  • 3,047
  • 25
  • 41
  • Suggest you try both and decompile to see what the IL looks like. (Then profile both to see if the output of the JIT compile is faster one way than the other.) (And then tell us what you find out, would be interesting to know. ;-) – yoyo Mar 24 '15 at 16:57
  • You will need to use AggressiveInlining [if the method compiles to more than 32 bytes of IL](http://blogs.microsoft.co.il/sasha/2012/01/20/aggressive-inlining-in-the-clr-45-jit/). Note in that article there are other restrictions on whether a method can be inlined at all. – stuartd Mar 24 '15 at 16:58
  • 1
    "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%", Knuth. See http://en.wikipedia.org/wiki/Program_optimization. – John Saunders Mar 24 '15 at 17:00
  • @yoyo: Could you please post a link/reference as to how to see 'what the IL looks like'. I understand the concept, but hasn't gone down that road yet. – holroy Mar 24 '15 at 17:01
  • You can use ildasm.exe from Microsoft (https://msdn.microsoft.com/en-us/library/f7dy01k1%28v=vs.110%29.aspx) or a tool like ILSpy (http://ilspy.net) to disassemble managed assemblies. – yoyo Mar 24 '15 at 17:09

2 Answers2

2

The problem is that you understand lambdas in c# incorrectly. When compiler translate c# to MSIL lambdas become classes and so you have nothing to inline. You can take a look at great Marc Gravell post on SO. So, whether or not you define lambdas in external class, you'll need to get an object from heap (i simplify compiled code behaviour). And so, as i think, there'll be no difference in performance for your application.

Community
  • 1
  • 1
Alex Voskresenskiy
  • 2,143
  • 2
  • 20
  • 29
  • I might very well understand lambdas incorrectly, as I know how to use them, but not necessarily what happens under the hood. Does the same apply for Action delegates which I just read (and updated question with) is used in the conditions? – holroy Mar 24 '15 at 17:12
  • @holroy Yes, it does. All c# delegates are implemented in such a way (on IL level) – Alex Voskresenskiy Mar 24 '15 at 17:13
1

Also keep in mind that the state machine keeps the delegate in its internal data structure. The guard action cannot be inlined there.

The only possible thing is to inline the methods that the helper method calls.

Urs
  • 228
  • 1
  • 6