.NET windows desktop apps speed?

[AleleVanuatu]

I'm no slouch programming (15 years experience) but don't have much experience with dotNET apps on the desktop.

What's your opinion on the speed and mem usage and feasibility of writing entire apps in C# while staying in the sandbox and not invoking native methods?

Let's take for example an NLE video editor, possible? Wordprocessor? Torrent client?

 

[Aberforth]

The speed depends on how well your code is written, many game engines and scientific applications are designed in .NET, there are many built-in optimizations like easy to use multi-threading and memory management features in the .net framework, so unless you use these features correctly you won't notice any significant improvement in performance.

.NET apps run a little slower when you run it for the first time - this is because the runtimes will be caching your apps assemblies.

 

[AleleVanuatu]

Ok how about any real .NET apps that are more than just (a) research projects (b) simple low-processing small apps?

Something like a real game engine, like you noted, would be nice to see. So far for simple guis and light processing I can see .NET, but for hardcore apps, I need to see the goods!

 

[Aberforth]

Originally posted by: AleleVanuatu
Ok how about any real .NET apps that are more than just (a) research projects (b) simple low-processing small apps?

Something like a real game engine, like you noted, would be nice to see. So far for simple guis and light processing I can see .NET, but for hardcore apps, I need to see the goods!

well there is 3D Mark Vantage, Roxio Easy Media Creator,a defragmentor program (I cant remember the name) but there are tons of apps based on .net.

But .NET isn't just a simple library, it has 14,000+ built-in classes. There are many layers within the .net.

Like WPF: Windows Presentation Foundation allows you to separate UI and the source code so the application programming is done by the developer and the UI by an artist. WPF applications like Expression Blend and Silverlight allows you to create hollywood like UI by generating XAML files with the standard .NET functionality.

But it is not necessary to do that- that's the beauty of .NET, with a standard IDE you can create apps that use normal winforms 2.0.


WCF: Windows Communication Foundation allows you to do network programming,SOAP,intercommunication and XML webservices.

http://en.wikipedia.org/wiki/ImageotNet3.0.svg
http://en.wikipedia.org/wiki/.NET_Framework

 

[degibson]

I would imagine .NET is fine for anything I/O bound.

 

[SoundTheSurrender]

I haven't written anything hardcore really but I did write a program that reads excel file and grabs 125 cells and creates a XML file. I read 10 excel files and it took 20 seconds. A co-worker was using a excel macro to do it and it took 5 minutes.

 

[DaveSimmons]

The "AAA" 3D game engines like Source, Doom3/id4, Rage/id5, Unreal3 will continue to be written in unmanaged C/C++ for a few more years because the developers want better control over memory use and to not add the overhead of .net.

XNA is fine for casual / light load engines without as many effects and with simpler models.

.Net should be fine for a word processor comparable to the one in OpenOffice written in Java. The real-time spell check, grammar check, dynamic formatting and menus that Word 2007 does might be too much for having good performance but the only way to know would be to try it.

Torrent and other network applications like FTP would be fine since they spend their time waiting for data packets to arrive. .Net has a lot of pre-written code for network messaging.

NLE: I'm guessing uncompressed is probably disk I/O bound. Doing the encoding will take a hit since the faster encoders use low-level assembly optimizations (such SSE single-instruction mutliple data instructions) that I don't think .Net is able to compile to directly. Still, if you remove your "pure .net only" restriction then a .Net application could call optimized external codecs.

 

[AleleVanuatu]

Yeah it looks like it's exactly what I thought it is. Winforms for easy guis, and easy coding with a more standardized library and more thought-out than say, Win32 or god-forbid, MFC.

Of course,if you call out to native functions, or native dlls that you write yourself, you can get the best of both worlds. And it looks a lot easier to do this than say use Java with JNI. Plus java has crappy UI compared to winforms, in my so-so uninformed/informed opinion. I know the Java Swing/AWT but not so much Winforms, but it looks better.

Still, it bothers me that it's so tightly bound to M$. Look what happened to the VB5, or VB6 programmers. I think it's better to go with open source languages if possible and call out to native dlls, of course this is not always possible because of work standards and corporate politics, but it can happen more often than naught.

Originally posted by: SoundTheSurrender
I haven't written anything hardcore really but I did write a program that reads excel file and grabs 125 cells and creates a XML file. I read 10 excel files and it took 20 seconds. A co-worker was using a excel macro to do it and it took 5 minutes.

That sounds like a perfect use-case. Perfect. Nice, decently fast solution, fast to write, and helps in day-to-day stuff. The new VB? LoL.

WPF sounds like a pipe-dream. Ah, maybe it'll pan out, or move things forward. I should look into that, it's definitely got a whizz-bang factor.

Honestly, .NET seems to be a slicker Java. I get flashbacks to 1996-2000 reading this. LoL.

I think the only thing that will continue to run unhampered for another 10 years is Win32/C. LoL!

 

[DaveSimmons]

Java but with a native Windows UI, a massive library including encapsulation of much of native win32 and other MS tech, and an escape hatch to link to unmanaged code.

.Net has also been very successful as a platform for third-party libraries including visual editing, charting, specialized UI widgets, etc. -- most vendors have moved from VB6 and C++ components to .Net

It seems perfect for internal corporate apps and for any shrink-wrap apps that don't need the best possible performance like action/fps games do.

Still, it bothers me that it's so tightly bound to M$. Look what happened to the VB5, or VB6 programmers.

You can still write new VB6 apps, and existing code still works, you just aren't getting new libraries from MS. Considering VB6 is a 1998 development tool I can't blame MS for moving on.

 

[WannaFly]

There is almost no case where something in the .NET framework isn't suitable. There are hardly any concerns about desktop app's speed, except when doing high performance things like game engines, etc. Even then you can call out to unmanaged dlls as stated. I've built 10-20 desktop programs on the .NET framework, given, all of them are line of business applications, but it's ideally suited for things like it. Yes, it might take a few seconds longer for it to start the first time, but it's just one of the tradeoffs.


You can't use the argument, "look what happened to the VB5 or VB6 programmers" - it's no different than any other languages over the years, PHP4 to PHP5, etc. They are all improvements for the better.

 

[Cogman]

As has been stated. .Net is fast enough. so to speak. The only places I can see it being is a problem in is in applications that need to be as fast as possible. And in cross-platform applications. Everything else it is really a good way to go. Especially if RAD is a must.

 

[Train]

Just as an example, Managed DirectX (the precursor to XNA) hit 99% of the performance of unmanaged DirectX. Its unlikely anyone really needs that last 1%, and the huge amounts of development/testing time saved makes .Net look pretty good.

As long as your app is well multithreaded, and coded efficiently, theres going to be no noticeable performance loss vs a C++ app. There may be a FEW cases in which you would want to take shortcuts and call directly to unmanaged windows API, as some open source C# apps do, but its not entirely neccesary.

 

[degibson]

We seem to have this general discussion a lot -- why don't we try some experiments? How would we go about constructing some experiments to evaluate some of our debates?

 

[Train]

Originally posted by: degibson
We seem to have this general discussion a lot -- why don't we try some experiments? How would we go about constructing some experiments to evaluate some of our debates?

I know theres tons out there, but all vary depending on what the app does. A process heavy on math will favor C++, a process heavy on I/O will all but eliminate C++'s speed gains.

I did read a blog recently (tried to find the link but couldnt) that said some JIT code has run faster than native code on newer, high end CPU's due to the fact that the CPU can interpret the short amount of intermediate code and run it faster than it can load the much longer native code and run that. Very interesting, but I assume that only applies in very specific cases. But that may point torward future app architectures as CPU speeds increase faster than I/O speeds.