IL waste of time

  • Thread starter Thread starter Doker
  • Start date Start date
D

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?
 
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?
Click to expand...

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.
 
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.
Click to expand...

Why would I want it to show ANYTHING when i build a release, in the
first place? ;>
 
Doker said:
Why would I want it to show ANYTHING when i build a release, in the
first place? ;>
Click to expand...

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?
 
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?
Click to expand...

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.
 
Doker said:
To put less optimization to JIT - reduce time to run app
Click to expand...

But at the same time making debugging harder
Not to thing does JIT Compiler does it or doesn't
Click to expand...

Not sure what you mean here.
Make app harder to decompile
Click to expand...

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.
Click to expand...

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.)
 
Back
Top