C# thoughts, opinions

[Earp]

If you don't know that C++ was (or wasn't) better, you must not have made a head-to-head comparison. I think that, if you do such a comparison, you'll see the problems in C# and WinForms very quickly.

If I had a couple years to spare to port the enough of the app to native C/C++ to do a head-to-head, I could do that. Heck, I might even keep the C/C++ version. Or I could spend a week and try to batch some sql queries together to save on network round trips, NGEN the assemblies to eliminate the JIT penalties, and try preloading some dlls earlier in the app if it ends up idle.

My point was that most performance problems for most developers, in my experience, aren't language/runtime related. CPU's are fast enough that users won't notice the difference.

 

[mikeblas]

I have done such a reimplementation on a large-scale project, and I was embarrassed to have to ship the managed code version of the product.

But you don't need years. Just do something simple: draw the UI for calc.exe, say, in both C# and MFC. It shouldn't take more than an afternoon, and the painting time, excessive page faults, and so on, will be readily apparent.

Or write an application which does disk I/O over a binary file. The brokenness in System.IO will make itself apparent pretty quickly, and you'll wish you had fwrite().

Or ...

Sure, there are classes of users who don't care about sluggish UI, and it might not be worth spending time and money on. But because of the problems in C# and .NET, I don't think I'm any more productive in those languages than C++ when writing commercial software.

 

[ShoeLace]

The most resource intensive app I've created ran excellent on a machine built 4 years ago. It was the first time I ever worked on a piece of an application that wasn't just 100% windows forms. I imagine the methods I used may have not been the best too since it was foreign to me.

One piece of the app does this:

It takes a pre-defined rect of your screen (400 pixels by 400 pixels). It copies that area of your screen, then zooms in by 400% and paints the contents of your screen into a form in real-time.

Then, based on user inputs multiple shapes/lines are drawn over that zoomed in rect.

The end result was a 100% flicker free non-buggy working version that used very little cpu time. This specific app had a very small user base (less than 10 people), but every person using it said it ran great. The system range was low end P4s up to current C2Ds.

Could it be done quicker in c/c++, I can't say for sure since I've never touched that language but I imagine it could -- but in the end it really doesn't matter. The c# build is "good enough".

 

[mikeblas]

but in the end it really doesn't matter. The c# build is "good enough".

And now you know what causes bloat ware.

We've already identified the C#-to-C++ comparison experiment as being incomplete. I bet we also don't know for sure that the users of these applications would not appreciate applications that loaded faster, took less memory, installed faster, and had snappier user response.

 

[ShoeLace]

We've already identified the C#-to-C++ comparison experiment as being incomplete. I bet we also don't know for sure that the users of these applications would not appreciate applications that loaded faster, took less memory, installed faster, and had snappier user response.

I don't think it can ever be complete. I'll blindly agree that a properly written c++ app will outperform c# in most tasks, even without ever working with c++ but that doesn't mean I think c++ is a 100% no-questions-asked superior language.

Superior is just too broad.

Btw I am an efficiency freak don't get me wrong, I just think c# is a good balance between performance (in most cases) and having the ability to put together an application quickly.

The day I write an app that doesn't have a snappy UI is the day I'll consider moving away from .net, so far this never came close to happening.