Å
姜天戩
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
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