locked
.NET assembly cache / ngen / jit image warm-up and cool-down behavior RRS feed

  • Question

  • Hi,

    I have an Input Method (IME) program built with C#.NET 2.0 DLL through C++/CLI. Since an IME is always attaching to another application, the C#.NET DLL seems not able to avoid image address rebasing.

    Although I have applied ngen to create a native image of that C#.NET 2.0 DLL and installed it into Global Assembly Cache, it didn't improved much, approximately 12 sec. down to 9 sec. on a slow PIII level PC.

    Therefore I uses a small application, which loads all the components referenced by the C#.NET DLL at the boot up time, to "warm up" the native image of that DLL. It works fine to speed up the loading time to 0.5 sec.

    However, it only worked for a while. About 30 min. later, it seems to "cool down" again.

    I know I can do the warm up rapidly by a tiny program. Still, is there any way to control the behavior of GAC or native image to be always "hot"? Is this exactly a image address rebasing problem?

    Thank you for your precious time.


    Sincerely,
    Mike
    Monday, September 14, 2009 8:16 PM

Answers

  • It is the file system cache that matters here.  You'll get quick load times when the assemblies can be loaded from cache instead of having to be read from the hard disk.  The first load is slow, subsequent are fast.  That explains the "cool down" too, the cached data gets replaced by other disk data.  There's not much you can do about this, it has to come from disk one way or another.  Using .NET 3.5 SP1 can help, it no longer verifies the strong name on trusted assemblies.  That requires reading the entire assembly instead of just the manifest and selected bits of IL.

    Old machines notoriously suffer from disk fragmentation, causing many read head seeks when loading a file.  Defragging the disk can do wonders for cold start times.  Defragging the paging file can be very important too, .NET JIT compiled code gets swapped to the paging file.  Beware that most standard defraggers don't defrag the paging file.  This utility works well, use it after defragging the drive.

    Hans Passant.
    • Marked as answer by eryang Monday, September 21, 2009 1:42 AM
    Tuesday, September 15, 2009 12:50 AM

All replies

  • oh dear, bad bad plan you should never ever write things like this in a managed language! Besides abusing a stupid ammount of memory by stating up a CLR in every proces you will run into problems with processes that already have a clr loaded or worse a different version (since any given process can only run 1 clr at a time) some things are better left to native code, this is one of them its one of those just because you can doesn't mean you should things..
    Monday, September 14, 2009 9:24 PM
  • It is the file system cache that matters here.  You'll get quick load times when the assemblies can be loaded from cache instead of having to be read from the hard disk.  The first load is slow, subsequent are fast.  That explains the "cool down" too, the cached data gets replaced by other disk data.  There's not much you can do about this, it has to come from disk one way or another.  Using .NET 3.5 SP1 can help, it no longer verifies the strong name on trusted assemblies.  That requires reading the entire assembly instead of just the manifest and selected bits of IL.

    Old machines notoriously suffer from disk fragmentation, causing many read head seeks when loading a file.  Defragging the disk can do wonders for cold start times.  Defragging the paging file can be very important too, .NET JIT compiled code gets swapped to the paging file.  Beware that most standard defraggers don't defrag the paging file.  This utility works well, use it after defragging the drive.

    Hans Passant.
    • Marked as answer by eryang Monday, September 21, 2009 1:42 AM
    Tuesday, September 15, 2009 12:50 AM