Forcing NET to Precompile EXE
-
My understanding is that when you run an EXE, it gets compiled by NET in chunks as you use various parts of the application. This method of execution has advantages for some types of computing. But i have the NEED for SPEEED! This app needs to respond quickly to user interaction at all times as if it was already compiled. My app runs great once it is fully compiled, but is unacceptably slow until it gets to this fully compiled state. Is there a way to instruct NET to precompile your EXE so that it runs at 100% speed from the start? If this causes the application loading to take longer, i accept this tradeoff as the app will start when the computer starts and i do not anticipate the user interacting with the app during this time.
-
My understanding is that when you run an EXE, it gets compiled by NET in chunks as you use various parts of the application. This method of execution has advantages for some types of computing. But i have the NEED for SPEEED! This app needs to respond quickly to user interaction at all times as if it was already compiled. My app runs great once it is fully compiled, but is unacceptably slow until it gets to this fully compiled state. Is there a way to instruct NET to precompile your EXE so that it runs at 100% speed from the start? If this causes the application loading to take longer, i accept this tradeoff as the app will start when the computer starts and i do not anticipate the user interacting with the app during this time.
try ngen.exe (native image generator)...it precompiles an assembly... call it like this: ngen - install NameOfAssembly
-
My understanding is that when you run an EXE, it gets compiled by NET in chunks as you use various parts of the application. This method of execution has advantages for some types of computing. But i have the NEED for SPEEED! This app needs to respond quickly to user interaction at all times as if it was already compiled. My app runs great once it is fully compiled, but is unacceptably slow until it gets to this fully compiled state. Is there a way to instruct NET to precompile your EXE so that it runs at 100% speed from the start? If this causes the application loading to take longer, i accept this tradeoff as the app will start when the computer starts and i do not anticipate the user interacting with the app during this time.
redfish34 wrote:
My app runs great once it is fully compiled, but is unacceptably slow until it gets to this fully compiled state.
There are various stages you are not considering, beside JIT compilation. - initialization of static data - initialaztion of instances - CPU cache To get everything precompiled (JIT'ed), use ngen on your assembly. I doubt that that will make as much difference as you hope for. Static data is by far the biggest bottleneck.
-
My understanding is that when you run an EXE, it gets compiled by NET in chunks as you use various parts of the application. This method of execution has advantages for some types of computing. But i have the NEED for SPEEED! This app needs to respond quickly to user interaction at all times as if it was already compiled. My app runs great once it is fully compiled, but is unacceptably slow until it gets to this fully compiled state. Is there a way to instruct NET to precompile your EXE so that it runs at 100% speed from the start? If this causes the application loading to take longer, i accept this tradeoff as the app will start when the computer starts and i do not anticipate the user interacting with the app during this time.
If you really need perfomance, VC++ should be your choice, not .NET. -------- "I say no to drugs, but they don't listen." - Marilyn Manson
-
redfish34 wrote:
My app runs great once it is fully compiled, but is unacceptably slow until it gets to this fully compiled state.
There are various stages you are not considering, beside JIT compilation. - initialization of static data - initialaztion of instances - CPU cache To get everything precompiled (JIT'ed), use ngen on your assembly. I doubt that that will make as much difference as you hope for. Static data is by far the biggest bottleneck.
leppie, thanks for your advice. I precompiled my exe using Ngen.exe and no performance gain was observed. It makes sense since most of the assemblies used by my app are already precompiled NET assemblies. So i add Ngen.exe to my long book of Microsoft urban legends (myths). I then tried a hack. I attempted to force precaching of forms by automating user interaction off-screen. I click buttons and cause forms to appear so they get cached. After this is done, the precached forms are presented to the user. Requires some dancing in the WndProc with custom messages. You need to wait until after the paint event to get the cached form. This works as long as the form is mostly visible on screen. When form is mostly offscreen, it does not work. This was a hopeful hack, but it came to a dead end. So after a long trip i have concluded that C# and all the NET languages, is not significantly different than VB6 in GUI performance. This is a disappointment. Luckily i used mostly Win32 calls in my app and not NET equivalents and so porting to C++ will not be to much of a problem.
-
leppie, thanks for your advice. I precompiled my exe using Ngen.exe and no performance gain was observed. It makes sense since most of the assemblies used by my app are already precompiled NET assemblies. So i add Ngen.exe to my long book of Microsoft urban legends (myths). I then tried a hack. I attempted to force precaching of forms by automating user interaction off-screen. I click buttons and cause forms to appear so they get cached. After this is done, the precached forms are presented to the user. Requires some dancing in the WndProc with custom messages. You need to wait until after the paint event to get the cached form. This works as long as the form is mostly visible on screen. When form is mostly offscreen, it does not work. This was a hopeful hack, but it came to a dead end. So after a long trip i have concluded that C# and all the NET languages, is not significantly different than VB6 in GUI performance. This is a disappointment. Luckily i used mostly Win32 calls in my app and not NET equivalents and so porting to C++ will not be to much of a problem.
redfish34 wrote:
So after a long trip i have concluded that C# and all the NET languages, is not significantly different than VB6 in GUI performance. This is a disappointment.
This not true.