.NET code execution...
-
Hi All, I have written a Windows application in C# running on Windows XP/2000 for .NET version 1.1 . When i execute the code, and load one of the modules for the first time, it takes around 3 sec. After unloading, when the same module is reloaded with all the same parameters, it takes only about 1 sec. All the conditions to reload the module are the same, all the SP's called are the same, which i cross verified by the ANTS performance profiler!!! But still there is considerable time difference!!! I thought that this difference was because of the JIT compilation which CLR does for the first time and for the successive times, JIT doesnt come into the picture, hence the time difference. But I tried generating the Native images (pre-compile the code) of the complete code using "ngen", and after observation, concluded that the behavior still pertained. I am now unable to locate the problem as in why the time difference exists? 1. Is it that im using "ngen" wrongly? 2. Is there some other reason for the strange behavior? I would be extremely thankful on receiving valuable inputs from the forum, Rajesh
-
Hi All, I have written a Windows application in C# running on Windows XP/2000 for .NET version 1.1 . When i execute the code, and load one of the modules for the first time, it takes around 3 sec. After unloading, when the same module is reloaded with all the same parameters, it takes only about 1 sec. All the conditions to reload the module are the same, all the SP's called are the same, which i cross verified by the ANTS performance profiler!!! But still there is considerable time difference!!! I thought that this difference was because of the JIT compilation which CLR does for the first time and for the successive times, JIT doesnt come into the picture, hence the time difference. But I tried generating the Native images (pre-compile the code) of the complete code using "ngen", and after observation, concluded that the behavior still pertained. I am now unable to locate the problem as in why the time difference exists? 1. Is it that im using "ngen" wrongly? 2. Is there some other reason for the strange behavior? I would be extremely thankful on receiving valuable inputs from the forum, Rajesh
-
Hi All, I have written a Windows application in C# running on Windows XP/2000 for .NET version 1.1 . When i execute the code, and load one of the modules for the first time, it takes around 3 sec. After unloading, when the same module is reloaded with all the same parameters, it takes only about 1 sec. All the conditions to reload the module are the same, all the SP's called are the same, which i cross verified by the ANTS performance profiler!!! But still there is considerable time difference!!! I thought that this difference was because of the JIT compilation which CLR does for the first time and for the successive times, JIT doesnt come into the picture, hence the time difference. But I tried generating the Native images (pre-compile the code) of the complete code using "ngen", and after observation, concluded that the behavior still pertained. I am now unable to locate the problem as in why the time difference exists? 1. Is it that im using "ngen" wrongly? 2. Is there some other reason for the strange behavior? I would be extremely thankful on receiving valuable inputs from the forum, Rajesh
For one thing, there is the file system's cache; whatever file is read, it ends up in this cache (its size could be something like 25% of your total memory, which can well be bigger than your application's exe file) so later executions of that exe (or its dlls) may be faster. Second, there are the security checks (of which I dont know any details); they may execute a lot faster second time around, probably also due to some caching. Third, Visual seems to require a few seconds when your application throws its very first exception (I dont know why this is), so be careful about any debugging/observation tool that is active during your tests. Further concerns: - is your exe very big ? - are there many many other files required (dlls, ....) ? - do they all reside on local disks ? - is any networking involved (which typically contains rather big timeouts) ? Finally, I would not suspect the JIT, I never had to really wait for it. Hope this helps. :)
Luc Pattyn
-
For one thing, there is the file system's cache; whatever file is read, it ends up in this cache (its size could be something like 25% of your total memory, which can well be bigger than your application's exe file) so later executions of that exe (or its dlls) may be faster. Second, there are the security checks (of which I dont know any details); they may execute a lot faster second time around, probably also due to some caching. Third, Visual seems to require a few seconds when your application throws its very first exception (I dont know why this is), so be careful about any debugging/observation tool that is active during your tests. Further concerns: - is your exe very big ? - are there many many other files required (dlls, ....) ? - do they all reside on local disks ? - is any networking involved (which typically contains rather big timeouts) ? Finally, I would not suspect the JIT, I never had to really wait for it. Hope this helps. :)
Luc Pattyn
Hi Luc Pattyn, Thanks for your valuable inputs.. While testing, none of the debugging tools were active.. i had ran the .exe of my application. My exe is not that big, though it requires around 20 dlls (20 projects in Visual Studio), one among them is really huge around 20MB, as it contains hundreds of images required by the application, and 4 COM components registered locally... Do you think this is a large number? And yes all these DLLs reside on local disks. If this is a large number, then should i think of redistributing code and reduce the number of DLLs?? I connect to DB on network, do you think this might create problems only for the first time? And for the remaining probabilities you said, is there a work around for those problems?? Have you come across situations like these??? I would be very thankful in getting further inputs from you, Regards, Rajesh
-
RajeshGuptha wrote:
2. Is there some other reason for the strange behavior?
The hardware and OS caching of the files that are loaded into memory? You should see the same sort of difference with a native EXE.
led mike
Hi Led Mike, Sorry i could not understand the comparison you are trying to mention here...If you dont mind could you please elaborate on that?? Regads, Rajesh
-
Hi Led Mike, Sorry i could not understand the comparison you are trying to mention here...If you dont mind could you please elaborate on that?? Regads, Rajesh
-
Hi Luc Pattyn, Thanks for your valuable inputs.. While testing, none of the debugging tools were active.. i had ran the .exe of my application. My exe is not that big, though it requires around 20 dlls (20 projects in Visual Studio), one among them is really huge around 20MB, as it contains hundreds of images required by the application, and 4 COM components registered locally... Do you think this is a large number? And yes all these DLLs reside on local disks. If this is a large number, then should i think of redistributing code and reduce the number of DLLs?? I connect to DB on network, do you think this might create problems only for the first time? And for the remaining probabilities you said, is there a work around for those problems?? Have you come across situations like these??? I would be very thankful in getting further inputs from you, Regards, Rajesh
Hi Rajesh, well I never did a 20 DLL project, so I cant tell you that is the culprit. And I sure would hope it is not, since DLLs are needed for component based development... But I suspect one of these two: - connecting to the DB could be the culprit; you might modify some code and try a run without DB (i.e. fake some data locally and watch the start-up speed). - Assuming you are starting your app (including loading images, and connecting to the DB) all sequentially, you could try to do (large parts of) the initialization asynchronously and in parallel, using a few separate threads. If this does not help, I would start looking to the DLLs. A possible experiment there is replace the big images DLL by something much smaller. For all of the above: - either keep the code as is, but include some logging a couple of lines such as Console.WriteLine(DateTime.Now.ToString("HH:mm:ss.fff")+" Starting/ending operation 3"); could reveal the bottleneck(s) - or change the functionality of the code, but dont spend the time to modify everything thoroughly (until you know for sure it needs the change), change just enough to be able to judge start-up speed differences. Regards,
Luc Pattyn
-
Hi All, I have written a Windows application in C# running on Windows XP/2000 for .NET version 1.1 . When i execute the code, and load one of the modules for the first time, it takes around 3 sec. After unloading, when the same module is reloaded with all the same parameters, it takes only about 1 sec. All the conditions to reload the module are the same, all the SP's called are the same, which i cross verified by the ANTS performance profiler!!! But still there is considerable time difference!!! I thought that this difference was because of the JIT compilation which CLR does for the first time and for the successive times, JIT doesnt come into the picture, hence the time difference. But I tried generating the Native images (pre-compile the code) of the complete code using "ngen", and after observation, concluded that the behavior still pertained. I am now unable to locate the problem as in why the time difference exists? 1. Is it that im using "ngen" wrongly? 2. Is there some other reason for the strange behavior? I would be extremely thankful on receiving valuable inputs from the forum, Rajesh
FYI I just rediscovered an MSDN article that might interest you: Improving Application Startup Time[^] but be warned most of its suggestions fall in the category: "if you like some feature because it is fancy, useful, powerful, you may not like its performance consequences." :)
Luc Pattyn
-
Hi Rajesh, well I never did a 20 DLL project, so I cant tell you that is the culprit. And I sure would hope it is not, since DLLs are needed for component based development... But I suspect one of these two: - connecting to the DB could be the culprit; you might modify some code and try a run without DB (i.e. fake some data locally and watch the start-up speed). - Assuming you are starting your app (including loading images, and connecting to the DB) all sequentially, you could try to do (large parts of) the initialization asynchronously and in parallel, using a few separate threads. If this does not help, I would start looking to the DLLs. A possible experiment there is replace the big images DLL by something much smaller. For all of the above: - either keep the code as is, but include some logging a couple of lines such as Console.WriteLine(DateTime.Now.ToString("HH:mm:ss.fff")+" Starting/ending operation 3"); could reveal the bottleneck(s) - or change the functionality of the code, but dont spend the time to modify everything thoroughly (until you know for sure it needs the change), change just enough to be able to judge start-up speed differences. Regards,
Luc Pattyn
Hi Luc Pattyn, Thanks a lot for your guidance. Ill try all the possibilities, and read the articles which you have suggested. Hope to get some positive results.. Will get back to you! Thanks and Regards, Rajesh
-
RajeshGuptha wrote:
could you please elaborate on that??
http://msdn2.microsoft.com/en-us/library/aa364218.aspx[^]
led mike
Hi Led Mike, Thanks for the guidance, Ill read the article, and get back if needed. Cheers, Rajesh