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.
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?
I think as much as anything it's likely to be the framework libraries and the CLR itself being in the Windows cache.
You may find that a tiny app which just sat in the background, maybe writing a byte to a file every minute (or some other pointless task which provided just enough activity to keep all the relevant files loaded in the cache) would do enough to keep things "warm."
It would at least be worth a try - it shouldn't take long to write at all.