Geeks With Blogs
Madhawa Learns To Blog : C#, Java .net, c#, java,sql, OOAD and more mad memory dumps...
When I’m dipping into improving performance of managed code I got wondered how compiler decides a method to inline or not.

Ok, First I’ll tell you what is method inlining (to whom, think what’s the hell is this inlining).

As all we know there is a cost associated with method calls; arguments need to be pushed on the stack or stored in registers, the method prolog and epilog need to be executed and so on. The cost of these calls can be avoided for certain methods by simply moving the method body of the method being called into the body of the caller. This is called Method In-lining. The JIT uses a number of heuristics to decide whether a method should be in-lined. The following is a list of the more significant of those (note that this is not exhaustive):

• Methods that are greater than 32 bytes of IL will not be inlined.
• Virtual functions are not inlined.
But if your virtual method is sealed its candidates for inlining as well as other compiler optimizations also.
• 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.
• If any of the method's formal arguments are structs, the method will not be inlined.


But note on, those things might be change in future versions of the JIT.
And other thing, don’t compromise the correctness of the method to attempt to guarantee that it will be inlined.
Pretty interesting? ha
Posted on Friday, June 16, 2006 7:35 AM Best of Old Blog | Back to top


Comments on this post: How compiler decides a method to inline or not?

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Madhawa Karunaratne | Powered by: GeeksWithBlogs.net