Hacker News new | ask | show | jobs
by peacemaker 5473 days ago
I think he hit the nail on the head referring to c# programmers in general not being as "performance conscious" which leads the misconception that c# is a much slower language to use. I've worked in many places and have come across the same thing. As a c++ programmer I have also worked with c# coders and am often shocked at their slap-dash approach to software engineering. I'm not saying they're all like that but it seems to be a common trend in my opinion!
5 comments

Maybe that's true, but I'm working on a Windows Phone 7 app right now that struggling to hit its performance targets. The major culprit? Silverlight's data-binding. Microsoft shipped the framework without shipping high performance controls necessary to meet the certification requirements of their app store (ListBox, I'm looking at you), so while our code might return the results of the list in <20ms, it takes another 800-1500ms for the results to be rendered. It's frustrating.
Have you tried using the virtualizing listbox?
From my research, it looks like the Listbox enables UI virtualization by default. It didn't help. I ended up finding some helpful soul's NavigationListControl and limiting the number of results until the user taps a "show all" button. It helped a little. I think the final solution will be pre-allocating the first N data items with empty strings so that the initial cost of the Listbox is incurred at initial-page-layout-time rather than at keypress-time.
I was solving similar problem but with a datagrid. I ended up adding my own scrollbar (so that I have better knowledge of what to preload) and populating the datagrid with an array of references to a single "Loading" object. The reduction in allocations sped it up a lot as well, I guess.
Do you think those programmers would suddenly become "performance conscious" if they switched to c++? What I'm saying is that I don't see the point in referring to them as "c# coders" they could be using any language just as badly.
Yeah I'd not label it a language issue but rather as you've already described it, as an implementation issue.
2 things:

1): Most projects that I've used c# for just aren't performance constrained. What's more important for us is the productivity dimension. We have _lots_ of hardware. We have a few programmers.

I've actually just finished the _only_ c# program that had a performance aspect. It was/is an in-house search engine. I profiled it, fixed the hotspots and it's fast enough.

2: MSFT Marketing. Linq|dynamic are heavily sold by Microsoft. You'll have to read Joe Duffy's blog for actual performance advice: http://www.bluebytesoftware.com/blog/2010/09/06/ThePremature...

True enough in general, but that cuts both ways -- I've worked with a number of longtime C++ guys that tend to optimize early, write long unreadable methods and seem positively allergic to standard OOP architectures, much less design patterns.
I think one of the big reasons is that most C# developers are ASP.NET CRUD developers, where, most the time the bottlenecks are in HTTP i/o and in waiting for the database results. Optimizing C# for these applications is a waste of time.

You will find that a greater proportion of C#/Winforms, console apps, windows services etc. developers are performance conscious.