Understanding C# Just In Time compilation 
Author Message
 Understanding C# Just In Time compilation

Hello All,

I read in a book that says when we compile a C# program,
the csc only puts the MSIL code in the EXE. and not
machine language code.

Now when we run it, the .net runtime reads the MSIL and
converts it to native machine language code.

The book also said that this is a one time activity and
that is why C# programs become faster and faster with time
(as more and more code gets transformed to native language
by the runtime).

Is this true? If the conversion of MSIL to native is one
time activity, then the date and time stamp of the exe and
the size of the exe should change whenever I run it.

But this does not seem to happen. The size of my
HelloWorld.exe is the same as what my csc compiler had
given me.

regards,
Abhishek.



Sun, 21 Mar 2004 14:00:14 GMT  
 Understanding C# Just In Time compilation
It happens in memory, and the compiled results are lost when for somewath
reason this memory released (for example your process is terminated)

An other option is to permanently precompile the whole .exe or .dll but this
is an other topic.

DirectZ


Quote:
> Hello All,

> I read in a book that says when we compile a C# program,
> the csc only puts the MSIL code in the EXE. and not
> machine language code.

> Now when we run it, the .net runtime reads the MSIL and
> converts it to native machine language code.

> The book also said that this is a one time activity and
> that is why C# programs become faster and faster with time
> (as more and more code gets transformed to native language
> by the runtime).

> Is this true? If the conversion of MSIL to native is one
> time activity, then the date and time stamp of the exe and
> the size of the exe should change whenever I run it.

> But this does not seem to happen. The size of my
> HelloWorld.exe is the same as what my csc compiler had
> given me.

> regards,
> Abhishek.



Sun, 21 Mar 2004 18:20:43 GMT  
 Understanding C# Just In Time compilation


Quote:
> Hello All,

> I read in a book that says when we compile a C# program,
> the csc only puts the MSIL code in the EXE. and not
> machine language code.

Yes.  The resulting EXE will contain the MSIL and the manifest.

Quote:
> Now when we run it, the .net runtime reads the MSIL and
> converts it to native machine language code.

The conversion is not done all at once.  It's done on a method by method
basis.  As the CLR hits a routine that has not been compiled, it
compiles it and keeps it in memory for the next call to that routine.

Quote:
> The book also said that this is a one time activity and
> that is why C# programs become faster and faster with time
> (as more and more code gets transformed to native language
> by the runtime).

It's a one time activity for ASP.NET apps.  For standard executables,
this process happens each time the application is run.

--
Patrick Steele



Sun, 21 Mar 2004 20:29:22 GMT  
 Understanding C# Just In Time compilation
Patrick wrotes:

Quote:
> It's a one time activity for ASP.NET apps.  For standard executables,
> this process happens each time the application is run.

This is not true.

When the .ASPX Web App is first run, then a C# or VB.NET code generator  g e
n e r a t e s  a source code file based on your .ASPX or ".CS code behind"
source pages. After it the compiler compiles this g e n e r a t e d  source
to a MSIL .DLL.   T h i s   happens really once.

But this process has nothing to do with JIT, because after outputting the
.DLL (once) the remaining process is similar to standard .DLLs and
Executables. The Runtime load them JITing them...etc

Of course there is a possibility to pre-compile a .DLL or a .EXE, but this
precompiling has nothing to do with .ASPX vs standard exe question.

DirectZ


Quote:


> > Hello All,

> > I read in a book that says when we compile a C# program,
> > the csc only puts the MSIL code in the EXE. and not
> > machine language code.

> Yes.  The resulting EXE will contain the MSIL and the manifest.

> > Now when we run it, the .net runtime reads the MSIL and
> > converts it to native machine language code.

> The conversion is not done all at once.  It's done on a method by method
> basis.  As the CLR hits a routine that has not been compiled, it
> compiles it and keeps it in memory for the next call to that routine.

> > The book also said that this is a one time activity and
> > that is why C# programs become faster and faster with time
> > (as more and more code gets transformed to native language
> > by the runtime).

> It's a one time activity for ASP.NET apps.  For standard executables,
> this process happens each time the application is run.

> --
> Patrick Steele



Mon, 22 Mar 2004 00:51:21 GMT  
 Understanding C# Just In Time compilation
Sounds like you're getting different responses.  Anyone from MSFT want to
comment?  It was my understanding that you could choose to have compilation
happen at runtime, or at installation time.  It was also my understanding
that until you updated your DLL or EXE, the compiled code sits in a cache on
the hard drive, and in memory if you're running the app.  I hope this helps!


Mon, 22 Mar 2004 00:56:18 GMT  
 Understanding C# Just In Time compilation


Quote:
> Sounds like you're getting different responses.  Anyone from MSFT want to
> comment?  It was my understanding that you could choose to have compilation
> happen at runtime, or at installation time.

That is correct.  Leave the EXE as-is and it will be JIT'd when run.  
Or, you could use the ngen utility to generate a native code executable
(at install time for example).

Quote:
> It was also my understanding
> that until you updated your DLL or EXE, the compiled code sits in a cache on
> the hard drive, and in memory if you're running the app.  I hope this helps!

I've heard this too, but I've never read it anywhere and I remember
seeing a post from someone (I believe it was someone from Microsoft)
that noted the JIT'd code is persisted in memory only.

--
Patrick Steele



Mon, 22 Mar 2004 01:41:57 GMT  
 Understanding C# Just In Time compilation
I think the difference with ASP.NET is that it holds onto the assembly that
it generates, so that the JIT is only done the first time a page is hit.


Quote:
> Sounds like you're getting different responses.  Anyone from MSFT want to
> comment?  It was my understanding that you could choose to have
compilation
> happen at runtime, or at installation time.  It was also my understanding
> that until you updated your DLL or EXE, the compiled code sits in a cache
on
> the hard drive, and in memory if you're running the app.  I hope this
helps!



Tue, 23 Mar 2004 02:16:00 GMT  
 Understanding C# Just In Time compilation


Quote:
> I think the difference with ASP.NET is that it holds onto the assembly that
> it generates, so that the JIT is only done the first time a page is hit.

So you're saying it holds on to the assembly it generates (which is IL)
and if the JIT is happening only once per page, it's also holding on to
the native code.

Am I reading that right?

--
Patrick Steele



Tue, 23 Mar 2004 04:32:07 GMT  
 Understanding C# Just In Time compilation


Quote:


> > I think the difference with ASP.NET is that it holds onto the assembly
that
> > it generates, so that the JIT is only done the first time a page is hit.

> So you're saying it holds on to the assembly it generates (which is IL)
> and if the JIT is happening only once per page, it's also holding on to
> the native code.

> Am I reading that right?

Yes. IIRC, the assembly is on disk (where all good assemblies live), but
when ASP.NET loads it, it keeps it loaded until it needs to unload it.


Wed, 24 Mar 2004 02:46:03 GMT  
 Understanding C# Just In Time compilation
Back to the _original_ question

My understandig was that .ASP or not .ASP is nothing to do with the original
question:
"Understanding C# Just In Time compilation"

When a page is first time hit, .ASP generates assemblies from our .ASPX
and/or code behind .CS files.

This is a two step process and happens only once:

Step one: First generates a temp .CS  or VB souce code file. (where there is
a generated custom page class derived from the .ASP Page class.)

Step two: Compiles this file to a .DLL with the appropriate compiler.

My understanding is: there is no essential difference between this
autogenerated .DLL and any other ,EXE and .DLL.

Both ( .ASP autogenerated .DLL and any other .DLL ) are MSIL  executables,
both are JITTED when executing , both can be (theoretically) pre-compiled
with various options with ngen util, and in the case of unloading from
memory the JITTED results are lost if they were not precompiled.

So the point of view of "Understanding C# Just In Time compilation" there is
no essential difference between .ASP and any other .DLL or .EXE

Of course that is true, that .ASP runtime try to keep in memory the .DLL and
not loading/unloading.


Quote:





> > > I think the difference with ASP.NET is that it holds onto the assembly
> that
> > > it generates, so that the JIT is only done the first time a page is
hit.

> > So you're saying it holds on to the assembly it generates (which is IL)
> > and if the JIT is happening only once per page, it's also holding on to
> > the native code.

> > Am I reading that right?

> Yes. IIRC, the assembly is on disk (where all good assemblies live), but
> when ASP.NET loads it, it keeps it loaded until it needs to unload it.



Wed, 24 Mar 2004 16:25:47 GMT  
 Understanding C# Just In Time compilation
Patrick,

There is a misunderstandable thing in Microsoft terminology about .ASP
technology:

Microsoft states that new .ASPX technology  precompiles pages.
This is very true. This means that C# in pages compiled to MSIL.
Also true that this happens only once, when the page first hit.

but this nothing to do with JIT ( because JIT is about MSIL to native
compiling )

So it is true that .ASPX pages are "precompiled",
Also true that this is happens only once when the page first hit.

But this does not mean that they are JITted only once.


Quote:


> > Hello All,

> > I read in a book that says when we compile a C# program,
> > the csc only puts the MSIL code in the EXE. and not
> > machine language code.

> Yes.  The resulting EXE will contain the MSIL and the manifest.

> > Now when we run it, the .net runtime reads the MSIL and
> > converts it to native machine language code.

> The conversion is not done all at once.  It's done on a method by method
> basis.  As the CLR hits a routine that has not been compiled, it
> compiles it and keeps it in memory for the next call to that routine.

> > The book also said that this is a one time activity and
> > that is why C# programs become faster and faster with time
> > (as more and more code gets transformed to native language
> > by the runtime).

> It's a one time activity for ASP.NET apps.  For standard executables,
> this process happens each time the application is run.

> --
> Patrick Steele



Wed, 24 Mar 2004 16:44:05 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. don't understand compile-time error

2. install-time compilation

3. Power at compilation time

4. pointers to function set at compilation time!!

5. Compilation Date/Time under Watcom

6. Date/time-of-compilation stamping C programs?

7. Very Hard to understand C# syntax in Microsoft's Web Data Admin Tool

8. Runtime Compilation in C#

9. Learning Linked Lists, Code Attached, My understanding of code attached, Please confirm understanding

10. Military Time in C#?

11. find time in C#

12. How to Get system time in C#?

 

 
Powered by phpBB® Forum Software