IL waste of time

[Doker]

Simple vb code:

<STAThread> _
Public Shared Sub Main()
Dim g As Integer = 3
Console.WriteLine(g)
End Sub


avaluates to:

..method public static void Main() cil managed
{
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor()
.entrypoint
.maxstack 1
.locals init (
[0] int32 g)
L_0000: ldc.i4.3
L_0001: stloc.0
L_0002: ldloc.0
L_0003: call void [mscorlib]System.Console::WriteLine(int32)
L_0008: ret
}



Look at lines 00 to 02
Load to eval stack
load off from the stack
load back to the eval stack

This code was generated with vb.net 2.0 in release mode with
optimizations enabled.

What is the meaning of this? Why is this done when it seams to by a
waste of pc power only?

 

[Jon Skeet [C# MVP]]

This code was generated with vb.net 2.0 in release mode with
optimizations enabled.

What is the meaning of this? Why is this done when it seams to by a
waste of pc power only?

It means the debugger can still show what's going on. The code is a
direct translation of what the source code shows.

What it will turn into when JIT-compiled (with optimisations on
*there*) is a different matter.

 

[Doker]

Jon Skeet [C# MVP] pisze:

It means the debugger can still show what's going on. The code is a
direct translation of what the source code shows.

Why would I want it to show ANYTHING when i build a release, in the
first place? ;>

 

[Jon Skeet [C# MVP]]

Why would I want it to show ANYTHING when i build a release, in the
first place? ;>

Optimised doesn't necessarily mean "don't produce debug information".
More to the point, why do you care? If the JIT optimisations mean
there's no cost, why would we want the C# compiler team to waste time
performing the optimisation earlier?

 

[Doker]

Jon Skeet [C# MVP] pisze:

Optimised doesn't necessarily mean "don't produce debug information".
More to the point, why do you care? If the JIT optimisations mean
there's no cost, why would we want the C# compiler team to waste time
performing the optimisation earlier?

To put less optimization to JIT - reduce time to run app
Not to thing does JIT Compiler does it or doesn't
Make app harder to decompile
See it's a good work and not waste time having doubts and asking here.
Have a feeling c# compiler is a compiler not a simple c# to stack
machine translator any child can make.
And more.

 

[Jon Skeet [C# MVP]]

To put less optimization to JIT - reduce time to run app

But at the same time making debugging harder

Not to thing does JIT Compiler does it or doesn't

Not sure what you mean here.

Make app harder to decompile

Not significantly, IMO.

See it's a good work and not waste time having doubts and asking here.
Have a feeling c# compiler is a compiler not a simple c# to stack
machine translator any child can make.
And more.

The C# compiler for version 1 was relatively simple - as of v2 (and
particularly v3) it does a lot more for you. I don't see optimisation
as particularly important at the C# -> IL level. There have been
examples where the C++/CLI compiler can produce IL which runs
significantly quicker than the C# code, but my suspicions is that
that's the exception rather than the norm. (It may always produce
faster code - it's the "significantly" part I have doubts about.)