c# definitive explantion of dotnet JIT compilation please and how to speed up performace

[Peted]

Hi,

im hoping someone cane provide or point to a definitive accurate
explantion of dotnet compilation when run and the best way to optimise
peformace when dotnet code is run first time and execution speed after
compliation.

Ive searched the net and seem to find various opinions on what
actually happens when you compile and run a c# dotnet application.
What im looking for is basicly how to make dotnet dlls load as fast as
possible and run as fast as possible

Eg

what exactly can ngen.exe do for speed and loading improvments

ive read with dotnet code is only compiled when methods are actually
called which would imply that everyone you start and app you can can
take a performance hit everytime a new piece of code is executed for
the first time.

In addition to that this all revolves around improving the performace
of a dotnet c# module hosted under a delphi win32 frame, with messages
passing between the two and the delphi host trapping some key events
in the c# module it is hosting.

The c# module is a sql database accessing module


Any advice or thoughts would be appreciated

Peted

 

[Marc Gravell]

Points to improve initial load time:

* note that 3.5 SP1 (later this year) includes some runtime-level
tricks for cold-start performance
* look carefully at what code actually executes during startup; you
might be able to "async" some of it and display something (incomplete)
sooner, and fill in the gaps as other code completes; in reality it
will take *longer*, but perception is everything...
* consider, where appropriate, tools like ngen to reduce JIT; I've
never used it myself... JIT performance has never been a significant
problem
* consider, where appropriate, tools like ilmerge to reduce the amount
of "fusion" time; "fusion" is resolving and loading the various
assemblies needed for your code as it runs

Points to improve execution performance:

* profile; find out what the code is spending most of the time on
* treat external data (network [web / database]) as suspect (high
latency)
* can any data access / data processing be done async?
* look carefully at your list etc data-structuers; sometimes swapping
a list for a dictionary, or finding a smart way to remove a nested
loop, can be the life saver; note that for short lists (say, <150, but
do your own measures), a simple list or array can be *more* efficient
than a dictionary : in one recent example swapping a dictionary for a
flat sorted array increased performance by a factor of 10 [but you
need to *measure* first]

And tons more... performance is a complex beast...

Marc

 

[Pavel Minaev]

But as far as I know, in C# all of the code in an assembly is compiled  
when the assembly is first loaded.

Nope, it's still JITted, though unlike Java which tries to postpone
this (i.e. it will first run the method through interpreter several
times before attempting the more expensive JITting), CLR will JIT
immediately on the first call. But not on assembly load.

Here's an article that covers it in more detail (among other things):

http://msdn.microsoft.com/en-us/magazine/cc163791.aspx

It actually explains the detailed layout of object vtables and format
JITter thunks. The latter is mostly applicable to 2.0 runtime as well
- I've successfully used the information in the article to patch those
thunks at runtime.

 The "global assembly cache" is, if I recall correctly, where the compiled code is then stored for future  
executions.

Not really. NGen does indeed store precompiled assemblies in GAC, but
GAC also stored plain assemblies as well. It's whatever you put there
using gacutil.

 

[Peter Morris]

Also, it looks to me as though the JIT compiler only compiles code when

it's first called, not when it's first loaded.

You saved me from correcting you If it were done when loaded it would
probably be called the "dont worry I did it ages ago compiler" rather than
the "just in time compiler"



Pete

 

[Arne Vajhøj]

Nope, it's still JITted, though unlike Java which tries to postpone
this (i.e. it will first run the method through interpreter several
times before attempting the more expensive JITting), CLR will JIT
immediately on the first call. But not on assembly load.

And the granularity is method not assembly.

Arne