C#: DON'T DO IT!!!
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
Tom Ollar wrote:
If you are thinking about building a "rich client" on the C# .Net Platform - think again.
I have done, sorry. My app does image processing, captures images from still and video cameras, processes video as well, etc.
Tom Ollar wrote:
So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#.
Like what ? Seriously, managed DirectX runs at 95% of the speed of C++ DirectX. All C# code gets compiled the first time it gets run, then it's native code. I'm interested to know what application you've written that cannot be optimised to work with C#. I would still be an advocate for C# being one possible tool, and C++ being a better one in some cases. Yours may well be a case for C++ as the best tool. I doubt, and my experience disproves, the idea that
Tom Ollar wrote:
Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it.
is a reasonable statement. Wait a minute - you're saying that OOP is a waste of time ? Christian Graus - Microsoft MVP - C++
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
Well, I must say I've used C# for smart client apps for the last 3 years, and I've never seen any problems with performance. Yes, the .NET Framework isn't everywhere, but the MFC DLLs weren't everywhere some years ago. But you didn't tell us, what does your company do with C#? -- LuisR
Luis Alonso Ramos Intelectix - Chihuahua, Mexico Not much here: My CP Blog!
The amount of sleep the average person needs is five more minutes. -- Vikram A Punathambekar, Aug. 11, 2005
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
Well, I have pretty much the following comment. The performance of any language is based equally, if not more so, on the skill of the programmer.
Tom Ollar wrote:
If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
:laugh: :rolleyes: Marc VS2005 Tips & Tricks -- contributions welcome!
-
Well, I have pretty much the following comment. The performance of any language is based equally, if not more so, on the skill of the programmer.
Tom Ollar wrote:
If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
:laugh: :rolleyes: Marc VS2005 Tips & Tricks -- contributions welcome!
He's actually written nine articles, all of them in C#. I suspect he's just having a bad day. I'm certainly interested to hear about his problem though. Christian Graus - Microsoft MVP - C++
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
Bad day? :laugh: That's not been my experience at all I've been using c# for years now, current project is a multi-tier business app with winforms and web front end and I used c++ since shortly after it was invented previously.
"Hello, hello, what's all this shouting, we'll have no trouble here! This is a Local Shop for Local People, there's nothing for you here!" -Edward Tattsyrup
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
Don't use C# with performance in mind - it's a pretty good language, kinda similar to VB.NET, except with a C++ like syntax. For performance, use VC++ 2005 in mixed-mode!
-
Don't use C# with performance in mind - it's a pretty good language, kinda similar to VB.NET, except with a C++ like syntax. For performance, use VC++ 2005 in mixed-mode!
Nishant Sivakumar wrote:
For performance, use VC++ 2005 in mixed-mode!
Why not use C++ natively if performance is the issue ? IMO, while this is good advice, most applications will not suffer from being written in C#.
Nishant Sivakumar wrote:
kinda similar to VB.NET
LIAR !!! :P Christian Graus - Microsoft MVP - C++
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
I am making an astronomical planetarium program, which can transform the ra/dec coords of 31857 stars, 646 constellation lines, and 514 deep sky objects, then draw all the objects on the screen, and guess how long it takes it? 0.08 seconds. And, it is C#. Perhaps C# isn't for everyone, but it works for me.
Pumk1nh3ad illustrates that Intelligent Design oft goes awry. - Ed Gadziemski You did'nt get it. I over estimated you. - Josh Gray -- modified at 22:00 Monday 21st November, 2005
-
He's actually written nine articles, all of them in C#. I suspect he's just having a bad day. I'm certainly interested to hear about his problem though. Christian Graus - Microsoft MVP - C++
Based on his comments in the post about GDI+, a couple of the articles (the 2010 concept IDE and the Mini Walker in particular), and a quick look at the web site referenced in his profile, it would appear he's using a whole lot of owner drawn custom controls. Maybe that's why his app's appear to be slower. Eric
-
Based on his comments in the post about GDI+, a couple of the articles (the 2010 concept IDE and the Mini Walker in particular), and a quick look at the web site referenced in his profile, it would appear he's using a whole lot of owner drawn custom controls. Maybe that's why his app's appear to be slower. Eric
That seems possible. If that's the case, one would assume the efficiency of his custom controls are the problem. I really hope he takes the time to answer here, even if it's only to say that he posted in the heat of the moment ( all the more if he actually backs up what he said ) Christian Graus - Microsoft MVP - C++
-
I am making an astronomical planetarium program, which can transform the ra/dec coords of 31857 stars, 646 constellation lines, and 514 deep sky objects, then draw all the objects on the screen, and guess how long it takes it? 0.08 seconds. And, it is C#. Perhaps C# isn't for everyone, but it works for me.
Pumk1nh3ad illustrates that Intelligent Design oft goes awry. - Ed Gadziemski You did'nt get it. I over estimated you. - Josh Gray -- modified at 22:00 Monday 21st November, 2005
You've written a program that puts 33,000 random dots on the screen in .08 seconds ? Cool. :P Christian Graus - Microsoft MVP - C++
-
You've written a program that puts 33,000 random dots on the screen in .08 seconds ? Cool. :P Christian Graus - Microsoft MVP - C++
They are not random dots. The stars are dots, the constellation lines are, of course lines, and the deepsky objects hace different icons to represent different types.
Pumk1nh3ad illustrates that Intelligent Design oft goes awry. - Ed Gadziemski You did'nt get it. I over estimated you. - Josh Gray
-
They are not random dots. The stars are dots, the constellation lines are, of course lines, and the deepsky objects hace different icons to represent different types.
Pumk1nh3ad illustrates that Intelligent Design oft goes awry. - Ed Gadziemski You did'nt get it. I over estimated you. - Josh Gray
Pumk1nh3ad wrote:
They are not random dots.
I love teasing you... :P Christian Graus - Microsoft MVP - C++
-
Pumk1nh3ad wrote:
They are not random dots.
I love teasing you... :P Christian Graus - Microsoft MVP - C++
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
-
I place this as a warning. If you are thinking about building a "rich client" on the C# .Net Platform - think again. It's slow. So slow that the guys in Redmond lapsed into stunned silence when I explained the kind of things my company does with C#. I heard this: "But what about performance?" "How's performance?" "You're using GDI+?" "So, how many objects get created with that code?" - in an admonishing tone, of course. and again - "What about performance?" These questions, coupled with the "Visual C++ - The Ultimate Language" poster on the second floor of building 41, kind of made me think that C# was a second class citizen, or worse... So just don't do it. Who cares about "managed code" and all that OOP crap - a 23mb Framework that's not installed ANYWHERE except stupid Windows Server 2003 and all that slow, slow, slow code simply isn't worth it. If you must have awesome UI use Flash and port it over to some PC emulator thingy - hell - ANYTHING is better than C#/Framework... Well that's it. You've been warned. If you still think that C#/Framework is a real alternative then I'll leave the rest to BRUTAL EXPERIENCE - which will certainly take care of you...
C# and the .NET core framework are fully capable of performing at a level that is competitive with that of native code. Initially I was worried that that would not be so, but the more I work with it, the more I find that, if you do things right, it is fully capable of good performance. But that "if" is very important. Firstly, C# lets you write code and design object-oriented libraries more easily, and at a higher level. This can cause many people to think less about the lower-level aspects of their application or component (performance, memory, etc) - until they have already coded it, and the performance problems hit them in the face. You have to keep those concerns in mind at all times - just as you would have to do when writing C++ code. You have to consider the performance implications of each design choice. Secondly, the .NET Framework is a different paradigm from what people coming from other backgrounds expect. To write performant code, you have to understand what is going on behind the scenes, and the dynamics of the framework that you are working with. But those dynamics are different from what people are used to. Each new way of doing things has both a good side and a bad side - and you have to consider both. I've seen even a lot of experts say things that demonstrate a lack of understanding of how the .NET framework works - simply because they have not yet had time to fully understand it. Now, that being said, there are, indeed, notable performance flaws in the non-core part of the .NET BCL, mainly having to do with native-to-managed interop wrappers. The .NET sockets implementation at least used to have scalability problems related to large numbers of transient connections, because of the way pinned objects were used. The Windows Forms wrapper suffers from a fair bit of slowness both because of interop and because the control classes derive from MarshalByRefObject, which does not benefit from a number of optimizations. The GDI+ wrapper would be much faster if it were not for the fact that interop is done in a very poor way performance-wise - buffer copies where they are not needed, poor use of caching, etc. Frank Hileman has considered abandoning the System.Drawing wrapper completely in favor of writing a custom GDI+ wrapper to get better performance by writing more efficient interop code. However, this is not a C# or core runtime problem, but a problem with the BCL, and even with the comparative slowness of the wrapper due to the way it is written, he has created a
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
I agree about the pointers. I can deal with those myself, and when I don't, I get a nice, easy to interpret GPF message ;) which indicates I need more coffee. Maybe it's a power trip, but I'd rather have the option of shooting my foot off with pointers, than having someone collect my garbage. It makes you more responsible, so you have to think about what you're doing. As far as writing components in MFC/ATL and using them in .NET, that's essentially going back to the VB6 days. C#/VB.NET is the next evolution of VB6, in my mind. I can't help thinking C# was created so people would think "oh, it's not BASIC" or "I know C++ now", just to satisfy management and curious end-users. Wrong! Suck it up and learn C++! P.S. .NET is too sloooow! Scott me up beamy!
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
Well, when C/C++ came around, people would have been saying "Real men use assembly language", before that "Real men use machine language" and so on. If you get a platform that offers you a lot of power and ease of use, I'd say go with it *when it is appropriate*, instead of clinging on to something you know. Regards Senthil _____________________________ My Blog | My Articles | WinMacro
-
Real men only use C/C++. Thanks to Microsoft for their language tools, but I can take care of my pointers, have done it before. Don't need any help on that. I believe that the only way .NET can survive is to write DLLs and Components in MFC/ATL and use them in .NET, and use .NET only as a front-end. That way you can satisfy stupid management that the code is written in C#/.NET. .NET is a complete waste of time. Just say NO to .NET! this is this.
That's great. You have fun with those pointers and memory leaks. In the meantime I'm going to concentrate on implementing functionality, not plumbing. cheers, Chris Maunder
CodeProject.com : C++ MVP
