.net and speed
-
starded programming with .net i see it is fast way to develop user interface also it offers heap of classes, i'm not sure but it seems to be stuff coded with .net runs wery slow just like VB6 app running trought it's VM:omg:.Maybe it's something wrong on my HD or is it really so slow i don't know. what do you think about it?
-
starded programming with .net i see it is fast way to develop user interface also it offers heap of classes, i'm not sure but it seems to be stuff coded with .net runs wery slow just like VB6 app running trought it's VM:omg:.Maybe it's something wrong on my HD or is it really so slow i don't know. what do you think about it?
Nonsense! .NET is fast! Blindingly so! Unlike the otherwise similar Java runtime, which is visibly slow. You are obviously a Java/Linux/Sun troll, and know nothing. :rolleyes: </sarcasm> Ok, ok... .NET stuff is great, but don't compare a proggy written in it to a similar C++ in terms of speed, esp. load time - your average C++ program has most of it's runtime loaded when you boot, vs. the .NET proggy which needs to have DLLs loaded, intialized, and then compile it before it actually gets a crack at doing whatever. Which makes it great for stuff that will be in memory a while and benefit from the .NET extras, but somewhat less so for tiny little utils you wish to run and use and kill quickly. Give it a couple years, and the average PC will be so fast you won't even notice (and MS will have released something slower...)
I think it's cool that Shog's coding johnson is longer than everyone elses -- JoeSox 10/8/03
-
Nonsense! .NET is fast! Blindingly so! Unlike the otherwise similar Java runtime, which is visibly slow. You are obviously a Java/Linux/Sun troll, and know nothing. :rolleyes: </sarcasm> Ok, ok... .NET stuff is great, but don't compare a proggy written in it to a similar C++ in terms of speed, esp. load time - your average C++ program has most of it's runtime loaded when you boot, vs. the .NET proggy which needs to have DLLs loaded, intialized, and then compile it before it actually gets a crack at doing whatever. Which makes it great for stuff that will be in memory a while and benefit from the .NET extras, but somewhat less so for tiny little utils you wish to run and use and kill quickly. Give it a couple years, and the average PC will be so fast you won't even notice (and MS will have released something slower...)
I think it's cool that Shog's coding johnson is longer than everyone elses -- JoeSox 10/8/03
-
starded programming with .net i see it is fast way to develop user interface also it offers heap of classes, i'm not sure but it seems to be stuff coded with .net runs wery slow just like VB6 app running trought it's VM:omg:.Maybe it's something wrong on my HD or is it really so slow i don't know. what do you think about it?
2 things: 1. Using clever programming, you can virtually drop the performance hit to nothing, except Application load time (where, as stated, all of the .NET dlls need to be loaded up) 2. NEVER take what the designer gives you at face value. I've boosted application speeds by over 50% by tinkering with the "Form Designer Generated" code. Sure, that means I can't use the designer anymore after I make my modifications, but I only use the designer to set up a baseline anyways. [EDIT] Make that 3 things: 3. Try to stay away from using enumerators whenever possible example:
DoodadCollection dc = ...; foreach( Doodad d in DoodadCollection dc ) { // do stuff with d }becomesDoodadCollection dc = ...; Doodad d = null; for( int i=0; i < dc.Count; i++ ) { Doodad d = dc[i]; // do stuff with d }[/EDIT] Jeremy Kimball -
2 things: 1. Using clever programming, you can virtually drop the performance hit to nothing, except Application load time (where, as stated, all of the .NET dlls need to be loaded up) 2. NEVER take what the designer gives you at face value. I've boosted application speeds by over 50% by tinkering with the "Form Designer Generated" code. Sure, that means I can't use the designer anymore after I make my modifications, but I only use the designer to set up a baseline anyways. [EDIT] Make that 3 things: 3. Try to stay away from using enumerators whenever possible example:
DoodadCollection dc = ...; foreach( Doodad d in DoodadCollection dc ) { // do stuff with d }becomesDoodadCollection dc = ...; Doodad d = null; for( int i=0; i < dc.Count; i++ ) { Doodad d = dc[i]; // do stuff with d }[/EDIT] Jeremy Kimball -
Thanks for hints. I think flaw i did was making complicated UI using form designer. I see also it is easy to write UI with net without form designer. alright.
Jeremy Kimball wrote: 3. Try to stay away from using enumerators whenever possible I agree - Enumerators are not the best for critical loops. There is a very good article on iterator performance[^] by Trevor Misfeldt elsewhere on CodeProject. However don't dismiss Enumerators completely - they are excellent if you have a very complex (nested) looping structure. It is excellent for hiding the implementation of that from calling code and make code readability and maintainability much better. --Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
-
starded programming with .net i see it is fast way to develop user interface also it offers heap of classes, i'm not sure but it seems to be stuff coded with .net runs wery slow just like VB6 app running trought it's VM:omg:.Maybe it's something wrong on my HD or is it really so slow i don't know. what do you think about it?
I've been working on a prototype in .NET and I'm getting very inconsistant performance results. On some systems, the prototype runs smoothly, on others you can watch the redraws happen. On my system, I can watch the delay while the JIT compiler kicks in on one operation, yet on another team members system you can't see the same thing. This variability actually worries me more than if was consistantly slow in certain operations. When all else fails, there's always delusion. - Conan O'Brien
-
I've been working on a prototype in .NET and I'm getting very inconsistant performance results. On some systems, the prototype runs smoothly, on others you can watch the redraws happen. On my system, I can watch the delay while the JIT compiler kicks in on one operation, yet on another team members system you can't see the same thing. This variability actually worries me more than if was consistantly slow in certain operations. When all else fails, there's always delusion. - Conan O'Brien
-
2 things: 1. Using clever programming, you can virtually drop the performance hit to nothing, except Application load time (where, as stated, all of the .NET dlls need to be loaded up) 2. NEVER take what the designer gives you at face value. I've boosted application speeds by over 50% by tinkering with the "Form Designer Generated" code. Sure, that means I can't use the designer anymore after I make my modifications, but I only use the designer to set up a baseline anyways. [EDIT] Make that 3 things: 3. Try to stay away from using enumerators whenever possible example:
DoodadCollection dc = ...; foreach( Doodad d in DoodadCollection dc ) { // do stuff with d }becomesDoodadCollection dc = ...; Doodad d = null; for( int i=0; i < dc.Count; i++ ) { Doodad d = dc[i]; // do stuff with d }[/EDIT] Jeremy Kimball1. fight the compiler 2. fight the tools 3. fight the language 4... use C++ ImgSource | CheeseWeasle
-
You mean, you can never know whether it works on a user system although it works fine on your.Man,well :sigh: i'll await and see what happens
Oh, it works, just sometimes very slowly. When all else fails, there's always delusion. - Conan O'Brien
-
1. fight the compiler 2. fight the tools 3. fight the language 4... use C++ ImgSource | CheeseWeasle
Chris Losinger wrote: 4... use C++ Don't forget to include the STL. ;)
-Nick Parker DeveloperNotes.com
-
I've been working on a prototype in .NET and I'm getting very inconsistant performance results. On some systems, the prototype runs smoothly, on others you can watch the redraws happen. On my system, I can watch the delay while the JIT compiler kicks in on one operation, yet on another team members system you can't see the same thing. This variability actually worries me more than if was consistantly slow in certain operations. When all else fails, there's always delusion. - Conan O'Brien
Joe Woodbury wrote: On my system, I can watch the delay while the JIT compiler kicks in on one operation, yet on another team members system you can't see the same thing. Do you have the option of Ngen'ing the executable; this would get rid of the JIT compilation.
-Nick Parker DeveloperNotes.com
-
Joe Woodbury wrote: On my system, I can watch the delay while the JIT compiler kicks in on one operation, yet on another team members system you can't see the same thing. Do you have the option of Ngen'ing the executable; this would get rid of the JIT compilation.
-Nick Parker DeveloperNotes.com
Nick Parker wrote: Do you have the option of Ngen'ing the executable; this would get rid of the JIT compilation. There's no real point during the debug cycle. When all else fails, there's always delusion. - Conan O'Brien