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
_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to