Format of .NET assemblies

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I have few questions about the format of .NET assemblies:

Are all .NET assemblies created in Portable Executable (PE) format only or
is there any other format supported? If so, which format gives better
performance?

Is Common Object File Format (COFF) related to .NET assemblies?

Thanks in advance,
Ravi.
 
Are all .NET assemblies created in Portable Executable (PE) format only or
is there any other format supported?
Click to expand...

If you target 64-bit platforms they can also be in PE+/PE64, if you
count that as a separate format.

Is Common Object File Format (COFF) related to .NET assemblies?
Click to expand...

Yes, since it's related to PE.



Mattias
 
Hi,

Thanks for the reply.

From my understanding, the code in PE format is the MSIL. During execution,
the JIT compiler converts MSIL to native code and executes it. Is there a way
to pre-convert MSIL into native code to avoid runtime overhead?
What is the format in which the native code is stored? (is it COFF even for
managed code also?)

Thanks,
Ravi.
 
Well you can run NGEN.EXE on the assembly on the deployment machine - this will cache a native image ono the disk.

Is this an overhead you are theoretically worried about or do you have evidence that JIT compilation is cauing you problems in your environment? NGEN doesn't come for free, there are also downsides to using it in 1.x (although some of these have been resolved with NGEN v2.0)

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi,

Thanks for the reply.

From my understanding, the code in PE format is the MSIL. During execution,
the JIT compiler converts MSIL to native code and executes it. Is there a way
to pre-convert MSIL into native code to avoid runtime overhead?
What is the format in which the native code is stored? (is it COFF even for
managed code also?)
 
You could use the "ngen" to compile your MSIL code. It could perhaps save a
bit especially at startup...

Other than that it's likely that the algoirhtms used will likely influence
much more the performance than the file format....

Patrice
 
Hi,

There is no evidence that JIT causes problems, but it is a theoretical
assumption that if we run a native executable, it would run faster.
Are there any problems with using NGEN.exe?

Thanks,
Ravi.

Are there any
 
An NGEN'd assembly will not run faster except at start up (code is only JIT'd once per program executing).

However, in 1.1 NGEN code *may* run slower as the runtime has to load both the native version and the IL version as the IL version contains the metadata the runtime needs to provide alot of the services it does. Because of the impact on working set, the program may, therefore have more paging taking place and so run slower. In addition, NGEN'd assemblies are "fragile" in that if any dependency changes the runtime must assume that any inlined methods may now be invalid and so reverts back to JITing.

However, Windows likes to share code images across processes which it cannot do with JIT'd code so NGEN can give an advantage there - but this depends on you NGENing an image that is used by alot of processes.

Version 2.0 puts the metadata in the native image to resolve the double load issue and has a background process that re-NGENs native assemblies that have been "broken" by dependency changes. So under version 2.0 NGEN is much morfe compelling. However, as with all performance optimizations make sure you test that it has helped before you go into production with it.

NGEN can help speed up start up time but won't necessarily.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi,

There is no evidence that JIT causes problems, but it is a theoretical
assumption that if we run a native executable, it would run faster.
Are there any problems with using NGEN.exe?

Thanks,
Ravi.

Are there any
 
Well, I don't think that at runtime you'll see any difference. I remember
reading some white paper from nasa (or some org like that) showing with a
math benchmark that the managed code is as fast as the native one, and
sometime maybe is faster!
 
Back
Top