[Mono-list] inlining of methods using structs

[Rüdiger Klaehn]

Tom Larsen wrote:

> "Inlining" is a function of the compiler. 

Inlining in .NET is a function of the JIT compiler that compiles the IL 
to native code. The compiler that compiles source code to IL code does 
not do any inlining.

> The runtime doesn't
> particuarlly care whether the next operator is a call onto a function or
> the function inline. 
 >
But the processor does care because a call instruction is much more 
expensive than pretty much any other instruction. And inlining makes 
subsequent optimizations like common subexpression elimination or 
enregistration possible.

 > The tradeoff is of course the classic "speed vs
> space".  A commonly used function might incur less of a performance hit if
> placed in line but you've increased the IL length of every function that
> is now using the code inline.
> 
We are not talking about IL. The inlining happens when the IL is 
JIT-compiled to native code. So the only downside is a slightly larger 
native code. But in most situations with structs this would be worth it.

> You seem to be under the guise that "structs" are lightweight.  There is
> noting about ECMA CLI specification that indicates this.  In fact
> "structs" can be quite complex.  The one blessing of the way C# over Java
> is this seperation of "objects" (classes) and "data" (structs) but nothing
> ever indicates that objects are heavier or lighter than structs.  If
> anything "structs" are harder to deal with because of box/unbox.
> 
Structs are allocated on the stack, so they need no GC. Additionally 
since they can not contain virtual methods they do not have a virtual 
method table and associated pointer. So structs *are* lightweight, at 
least compared to objects. Boxing and unboxing are only an issue if you 
want to treat your structs as objects, and not in normal usage. In the 
example I included the struct Complex is never boxed or unboxed.

best regards,

Rüdiger