How small do methods have to be for them to be inlined in the main method?

Question

If I create a dll called xaisoft.dll like this:

Using System;
Using System.Reflection;

[assembly:AssemblyVersion("1.0.0.0")]
public class XaiSoft
{
    public string PrintName()
    {
        return "XaiSoft";
    }
}

and then compile it with

csc /t:library lib.cs

and then create a process assembly to use my library like so:

Using System;
Using System.Reflection;

class App
{
    static void Main()
    {
        ShowAssemblies("Before creating type");
        ShowName();
        ShowAsseblies("After creating type");
    }

    static void ShowName();
    {
        XaiSoft x = new XaiSoft();
        Console.WriteLine("Name: {0}", x.PrintName());
    }

    static void ShowAssemblies(string message)
    {
        Console.WriteLine(message);
        foreach(Assembly a in AppDomain.CurrentDomain.GetAssemblies())
        {
            Console.WriteLine(a.FullName);
        }
     }
}

Now, if I compile the above with csc app.cs /r:XaiSoft.dll

and then run it

I will see that the XaiSoft.dll is loaded even before PrintName from XaiSoft is called.

This brings me to my questions:

I read that the reason it does this is that when the runtime JIT compiles the method, it inlines small methods call by the current method (Main). How small do the methods have to be in order for them to be inlined? and by inlining does it mean it extracts the contents of ShowName and puts it directly in the Main method.

I also read that when once a method is JIT compiled, it is cached in memory, I am a little confused by this. This is only when your application is running right? If I close it down and run it again, does it have to JIT compile my method again?

Can someone explain the statement : To Successfully JIT Compile a method, the runtime must have access to the types used by the method, so the runtime will load the assemblies that contain those types. Is the answer to the previous statement, the runtime will laod the assemblies that contain those types so it can jit compile the method or would changing the access modifier to private prevent it from being jit compiled

Also, does the compiler keep inlining methods within methods that they are called if they are small enough:

For example if I have the following code snippet:

   static void Main()
   {
      ShowName();
   }

   static void ShowName()
   {
      ShowAge();
   }

   static void ShowAge()
   {
       ShowGender();
   }

   static void ShowGender()
   {
     //Show gender code
   }

Would Main inline ShowName, ShowName inline ShowAge, ShowAge inline ShowGender? If it did do that, would it go further and would main end up inlining everything.

Answer 1

According to Eric Gunnerson, the method has to be small enough to fit into 32 bytes of IL.

The criteria listed there are still valid, I believe, except the last one. .NET 3.5sp1 now allows methods that take structs as arguments to be inlined. The current list is:

• Methods that are greater than 32 bytes of IL will not be inlined.
• Virtual functions are not inlined.
• Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.
• Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.

As for your questions:

Would Main inline ShowName, ShowName inline ShowAge, ShowAge inline ShowGender?

The Show*** methods would most likely all get inlined. I do not believe Main would get inlined, especially considering it will become >32 bytes of IL.

Answer 2

Assemblies are loaded when types are referred. Your ShowName method uses the type XaiSoft, so the corresponding assembly must be loaded before an instance of this type can be created.

Code is JIT compiled and stored as compiled code in the process as hand. Thus JIT compiled code is not shared between two instances of the same application nor is it saved for later use.

Small methods may be inlined by the compiler, but you can prevent it from being inlined by using the MethodImplAttributes.NoInlining attribute.

Answer 3

It sounds like you might be looking for a way to stop inlining. You can opt out of inlining by applying the System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining) attribute to your method/property or constructor.

Answer 4

I would point out that one should never write code that relies on any expectations about how the CLR jitter will operate. For one thing, the algorithms used in the JIT compiler are constantly evolving and will quite likely change in the future. Furthermore, the jitter is generally in a better position to decide whether an optimization like inlining should be performed.

JIT'ed code is only available to a single process (not across processes) nor is it in any way (that I am aware of) cached between executions of your program. The JIT compiler needs access to any types using in a method in order to compile it - this include both public and private methods.

You can suppress inlining using the MethodImplAttribute(MethodImplOptions.NoInlining) attribute on the method; however, you cannot force inlining.