Speedup app startup time
-
Is there any way to speed up the startup time of a winforms application? The thing takes nearly a minute to startup! This is on a pretty low end machine (P133) but it runs fine once it's going.
You can run the install time JITter on it.
ngen [assembly name]In this case Assembly Name would be the executable. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971 -
You can run the install time JITter on it.
ngen [assembly name]In this case Assembly Name would be the executable. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971 -
Are you running the command on the machine you are testing it on? You could also run ngen on any non-system assembly that you use. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
-
Are you running the command on the machine you are testing it on? You could also run ngen on any non-system assembly that you use. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
Yes, I ran it on the machine its running on. It seemd to make no difference at all in startup time. James T. Johnson wrote: You could also run ngen on any non-system assembly that you use. I dont quite understand this? The program is a database app... when started nothing happens for a while then the UI starts to draw then nothing happens again for a while, then finally the rest of the UI draws and away we go. Maybe the connection to the database is whats slow? (although its just a local MDB database).
-
Yes, I ran it on the machine its running on. It seemd to make no difference at all in startup time. James T. Johnson wrote: You could also run ngen on any non-system assembly that you use. I dont quite understand this? The program is a database app... when started nothing happens for a while then the UI starts to draw then nothing happens again for a while, then finally the rest of the UI draws and away we go. Maybe the connection to the database is whats slow? (although its just a local MDB database).
paulb wrote: Maybe the connection to the database is whats slow? (although its just a local MDB database). Beings that your db is local, I can only assume the time delay could be related to the processor speed(P133 and .NET application?). Nick Parker
-
Yes, I ran it on the machine its running on. It seemd to make no difference at all in startup time. James T. Johnson wrote: You could also run ngen on any non-system assembly that you use. I dont quite understand this? The program is a database app... when started nothing happens for a while then the UI starts to draw then nothing happens again for a while, then finally the rest of the UI draws and away we go. Maybe the connection to the database is whats slow? (although its just a local MDB database).
Is ur machine on a domain based network, if thats the case there is a bug in the framework (which can be worked around) which increases the app startup time. It has something to do with the 'aspnet' user account which needs to be configured on the deployed machines under the 'guest' users. I happen to see this on the .net mailing list. If this isnt (the machine not on a domain) the case, I think you will have to accept the fate. Cheers Kannan
-
You can run the install time JITter on it.
ngen [assembly name]In this case Assembly Name would be the executable. James Sonork: Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971I tried running the ngen utility on couple of programs I have written, there doesnt seem to be any significant improvement in performance. Is it something to do with any of the command line switches or to do with it will only work for certain type of apps. Have you tried using ngen and seen any performance improvement. Also, I believe that ngen simply reduces the process of the IL being compiled during the time of invokation(ie if u use ngen on a assembly the process of compilation to machine code after loading the assembly is skipped). Is this the right understanding. Thanks Kannan
-
I tried running the ngen utility on couple of programs I have written, there doesnt seem to be any significant improvement in performance. Is it something to do with any of the command line switches or to do with it will only work for certain type of apps. Have you tried using ngen and seen any performance improvement. Also, I believe that ngen simply reduces the process of the IL being compiled during the time of invokation(ie if u use ngen on a assembly the process of compilation to machine code after loading the assembly is skipped). Is this the right understanding. Thanks Kannan
Yes, thats the correct understanding... Here's why Currently there are two JITters with .NET, the runtime JIT and the install-time JIT. The runtime JIT is what you get by default; it works a method at a time. The install-time JIT takes an entire assembly and performs the MSIL -> x86 conversion on it. The performance improvement you see depends on how your program is structured, if you do a lot of processing on startup (and probably a lot of method calls) then running the install-time JIT will help out because you won't incur the JIT for every method call. If you don't do a lot of startup processing then there is a good chance you won't see any effect right away if at all. But (!) there is no guarantee that the framework won't re-JIT your assembly even if you've run ngen on it. If it thinks there is a reason to believe the underlying IL has changed it will reJIT the assembly, but I cannot remember if it reJITs all of it or if it reverts back to runtime JITting. James Simplicity Rules!
-
Yes, thats the correct understanding... Here's why Currently there are two JITters with .NET, the runtime JIT and the install-time JIT. The runtime JIT is what you get by default; it works a method at a time. The install-time JIT takes an entire assembly and performs the MSIL -> x86 conversion on it. The performance improvement you see depends on how your program is structured, if you do a lot of processing on startup (and probably a lot of method calls) then running the install-time JIT will help out because you won't incur the JIT for every method call. If you don't do a lot of startup processing then there is a good chance you won't see any effect right away if at all. But (!) there is no guarantee that the framework won't re-JIT your assembly even if you've run ngen on it. If it thinks there is a reason to believe the underlying IL has changed it will reJIT the assembly, but I cannot remember if it reJITs all of it or if it reverts back to runtime JITting. James Simplicity Rules!
Thanks James for the Info'. I never knew anything on reJITing ...:-O but I couldnt follow when you said the underlying IL has changed.. u mean how the m/c code is aligned or something of that sort ..Any idea on how do I do the install time JIT stuff, I remember long ago I read an article which said the JITing happens not once or all at a time but only when a particular portion of the code is used eg. a method call is done. thanks Kannan
-
Thanks James for the Info'. I never knew anything on reJITing ...:-O but I couldnt follow when you said the underlying IL has changed.. u mean how the m/c code is aligned or something of that sort ..Any idea on how do I do the install time JIT stuff, I remember long ago I read an article which said the JITing happens not once or all at a time but only when a particular portion of the code is used eg. a method call is done. thanks Kannan
Kannan Kalyanaraman wrote: but I couldnt follow when you said the underlying IL has changed.. In a .NET application it is possible to change the image of the assembly at runtime. John Lam does this in his aspect weaver, and the JITter does this whenever it JITs a method [before a method is JITted the x86 has a jmp to a stub function that does the JIT, that jmp is then replaced once the method has been JITted]. Kannan Kalyanaraman wrote: Any idea on how do I do the install time JIT stuff ngen is the install-time JIT utility, so you'd just run that program during your setup. Kannan Kalyanaraman wrote: I remember long ago I read an article which said the JITing happens not once or all at a time but only when a particular portion of the code is used eg. a method call is done. The runtime JIT works this way. When a method is JITted any method calls are looked up to see if the method has already been JITted, if it has it outputs an x86 jmp instruction to that method's x86 code; if it hasn't been JITted it instead outputs a jmp instruction to a stub function, which when executed will start the JIT process. James Simplicity Rules!