I just can't believe some of the stuff being said in this thread....^_^
Anyways, as stated before twice, you can precompile .NET programs using NGen.
In general .NET performance:
-Has an advantage thanks to ultra fast memory allocation and good locality of reference( related objects tend to fit in cache, less cache misses/stalls ).
-Is at a disadvantage against the best "native" optimizing compilers because of codegen. They get all the time in the world to chew on code, while the jit has to work on the millisecond level. That said, the quality of code improved from 1.0 to 1.1, and from 1.1 to 2.0 by alot. ( Just think about this. Right now it can compete and/or out perform programs output by native compilers. Its only going to get better. )
-Theres also the hit when calling native libraries. The runtime will marshall( convert ) managed types to non managed, and vice versa. For complex types this can be expensive... for simple blittable types( int, float, etc )-- its cheap.
Also unless the call has been marked with the SuppressUnmanagedCodeSecurity attribute-- the runtime may perform an expensive security check. ( This again falls under people not knowing what they are doing )
Regarding a win32 app vs a win forms app. You have to be crazy to try to compare the two.
Win32 in all its glory! ( Thank god code::blocks has a template eh? )
System.Windows.Forms and c#( this would be even shorter in boo )
The resulting binaries weigh in at 20k for win32, and 4k for the c# version. Both versions start in the same amount of time on my machine, but granted-- you do plop more stuff in to the app and the .net one will take longer to start up than the native. As far as startup time goes... I really don't care. The pro's outweigh the cons by far.
The c# version should also run on linux and mac, or any platform where mono exists, without a recompile :O
Comparing performance for event driven apps doesn't make sense, but supposing we did have any kind of gadgets and logic involved, you'd end up in a situation where once again, the .NET version was much easier to code and maintain, while keeping the same level of performance.
You should read the article about rico mariani and raymond chen, writing a chinese/english dictionary reader( C++ converted to a C# version ).
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx
After 6 iterations of code, the c++ version managed to outperform the c# one( Which was ahead by iteration #2 ).
Excerpt..
"...The managed code got a very good result for hardly any effort. To defeat the managed Raymond had to:
Write his own file/io stuff
Write his own string class
Write his own allocator
Write his own international mapping
"
If that doesn't open your eyes, then I don't know what will.
Anyways, as stated before twice, you can precompile .NET programs using NGen.
In general .NET performance:
-Has an advantage thanks to ultra fast memory allocation and good locality of reference( related objects tend to fit in cache, less cache misses/stalls ).
-Is at a disadvantage against the best "native" optimizing compilers because of codegen. They get all the time in the world to chew on code, while the jit has to work on the millisecond level. That said, the quality of code improved from 1.0 to 1.1, and from 1.1 to 2.0 by alot. ( Just think about this. Right now it can compete and/or out perform programs output by native compilers. Its only going to get better. )
-Theres also the hit when calling native libraries. The runtime will marshall( convert ) managed types to non managed, and vice versa. For complex types this can be expensive... for simple blittable types( int, float, etc )-- its cheap.
Also unless the call has been marked with the SuppressUnmanagedCodeSecurity attribute-- the runtime may perform an expensive security check. ( This again falls under people not knowing what they are doing )
Regarding a win32 app vs a win forms app. You have to be crazy to try to compare the two.
Win32 in all its glory! ( Thank god code::blocks has a template eh? )
#include <windows.h> LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); char szClassName[ ] = "MyWindow"; int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nFunsterStil) { HWND hwnd; MSG messages; WNDCLASSEX wincl; wincl.hInstance = hThisInstance; wincl.lpszClassName = szClassName; wincl.lpfnWndProc = WindowProcedure; wincl.style = CS_DBLCLKS; wincl.cbSize = sizeof (WNDCLASSEX); wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; wincl.cbClsExtra = 0; wincl.cbWndExtra = 0; wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; if (!RegisterClassEx (&wincl)) return 0; hwnd = CreateWindowEx ( 0, szClassName, "My Window", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 640, 480, HWND_DESKTOP, NULL, hThisInstance, NULL ); ShowWindow (hwnd, nFunsterStil); while (GetMessage (&messages, NULL, 0, 0)) { TranslateMessage(&messages); DispatchMessage(&messages); } return messages.wParam; } LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_DESTROY: PostQuitMessage (0); break; default: return DefWindowProc (hwnd, message, wParam, lParam); } return 0; }
System.Windows.Forms and c#( this would be even shorter in boo )
using System; using System.Drawing; using System.Windows.Forms; public sealed class MyWindow : Form { public MyWindow() { Text = "My Window!"; Size = new Size( 640, 480 ); } [STAThread] static void Main() { Application.Run( new MyWindow() ); } }
The resulting binaries weigh in at 20k for win32, and 4k for the c# version. Both versions start in the same amount of time on my machine, but granted-- you do plop more stuff in to the app and the .net one will take longer to start up than the native. As far as startup time goes... I really don't care. The pro's outweigh the cons by far.
The c# version should also run on linux and mac, or any platform where mono exists, without a recompile :O
Comparing performance for event driven apps doesn't make sense, but supposing we did have any kind of gadgets and logic involved, you'd end up in a situation where once again, the .NET version was much easier to code and maintain, while keeping the same level of performance.
You should read the article about rico mariani and raymond chen, writing a chinese/english dictionary reader( C++ converted to a C# version ).
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx
After 6 iterations of code, the c++ version managed to outperform the c# one( Which was ahead by iteration #2 ).
Excerpt..
"...The managed code got a very good result for hardly any effort. To defeat the managed Raymond had to:
Write his own file/io stuff
Write his own string class
Write his own allocator
Write his own international mapping
"
If that doesn't open your eyes, then I don't know what will.