C#: DON'T DO IT!!!
-
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
-
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!
-
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.
Real men don't use computers, they use there own brain power... Seriously though, while you take out the garbage I'll add functionality. I'm not saying unmanaged code is useless. Its a tool, tools are supposed to make our lives easier. Why use stone and chisel when you can use pencil and paper. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
-
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
Well said, I have a question for you. What profiler do you use? I used the analysis tool that was in the Betas but I can't find it in the Pro version (guessing they put it in Team System) but I am looking for one. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
-
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
Chris Maunder wrote:
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.
Did we code one too many lines of FORTRAN (yes, it deserves capital letters ;P ) Chris? Or, perhaps, you just weren't man enough to handle pointer arithmetic? ;)
-
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!
On his defence, if its GDI+ that is his problem , he's quite right about performance problems. gdi+ is 100% software rendered and slow as crap compared to real native gdi. (even if people claim gdi+ to be a wrapper over native gdi which I would claim it isnt since it doesnt allocate gdi resources in your process (ok, it does in some cases eg if you get a hdc or hfont etc) and yes , i know its very possible to get decent rendering speeds with hardcore smart redraw optimizations in gdi+. (and Ive seen vg.net) but you can get better rendering speed in native gdi w/o any optimizations at all. So I will agree with him and say that gdi+ is slow as crap. but on the other hand , that has nothing to do with c# :)
-
Well said, I have a question for you. What profiler do you use? I used the analysis tool that was in the Betas but I can't find it in the Pro version (guessing they put it in Team System) but I am looking for one. Matt Newman
Even the very best tools in the hands of an idiot will produce something of little or no value. - Chris Meech on Idiots
For memory-related profiling, I've always used the CLR Profiler[^]. It has a whole bunch of memory-related graphs and statistics. For CPU-usage-related profiling, at first I just used timing code inserted at various points. Then I started using NProf[^] (which seems to be perpetually in 'alpha' stage :rolleyes: ). It gives you basic statistics related to performance each method in your application (time taken for each is given as a percent of the overall time). Then I started using the VS2005 profiler, which is very convenient and pretty good as well - but now that I've upgraded to the RTM it's gone. :(( I've heard that the Ants Profiler[^] is good, so I think I'm going to check it out.
