According to some the .NET framework is still "an inefficient bundle of code"
My last post, provoked a few replies. First
Jon Udell wrote:
It's always problematic to define what's meant by speed in cases like this. Application load time? GUI responsiveness? Data transfer? Every .NET app I've used loads slowly -- particularly when it's the first .NET app in use, but even otherwise. GUI responsiveness varies from sluggish to snappy, which I attribute to differing degrees of experience with the Framework and with the managed environment that supports it. Data transfer that isn't gated by your network pipe its mainly an algorithmic thing that depends on caching, not the runtime.
I think we're in agreement:
- Application load time - can be slow, especially if yours is the first .NET app loaded since you have pay for the CLR and all its libraries to load.
- GUI responsiveness - its hard work in any platform. .NET is no worse than any other. Since WinForms is just a wrapper around the old Win32 controls performance shouldn't be radically different. The difficult part is making the application respond event when work is going on in the background
- Data Transfer/Computation - is almost always an algorithmic/implementation problem.
When I said .NET performance is "a real issue that will dog client-side .NET in the same way, and for the same reasons, that it has dogged client-side Java," I did not mean that I believe, as Vaughan-Nichols does, that use of .NET automatically means sluggish performance. In fact I don't think that. But the perception does exist, as it has existed for Java, despite evidence to the contrary (e.g., Eclipse), because there is also evidence to support it. Modern managed runtimes are a huge and necessary step forward, but the desktop is an unforgiving environment in which to deploy apps that depend on them. That's been a challenge for Java, and it's a challenge for .NET too.
Steven J. Vaughan-Nichols, however had a very different reply (I quote with permission from a private email):
It's an "inefficient bundle of code."
I've covered software development for some times, primarily Java, and
like most JVM borne programs, I've found that .NET Framework progams
are far slower than similar programs written directly to the Windows
APIs. This was especially true of the programs I looked at for the
Post, where the .NET Framework programs lagged far behind their
brethern.
The problem with JVM, .NET FrameWork and older BASIC programs have
always been that while they make it easy to write fairly elaborate
end-user programs, they also make performance tuning much harder.
Thus, for my money, you might want to prototype your baby in .NET
Framework, but for a program to offer the world, you'll want to
finish the job in C++, C# or some such.
Wow. I'm not sure where to start. I assume Steven knows that C# is a CLR/.NET based language. Much of what Steven said was true of the older JVM's (1.0, 1.1, 1.2), by version 1.3 performance was getting pretty snappy (even with swing). For evidence of this just try doing development work in Eclipse (or even JBuilder 4 - the last version I used).
As for the performance of the .NET framework vs native code, well its actually quite close.
- The WinForms components are just wrappers around the native Win32 controls - so the same performance issues have to be solved in either case.
- Garbage Collection - I just walked our application through a typical run and less than five percent of the runtime was spent in GC. Not really an issue.
- Interpreted languages - there are plenty of articles kicking around the internet showing that the CLR performance while not yet as good as native performance is still pretty good.
I think what Steven has noticed is that some developers haven't paid enough attention to performance in their applications. The challenge to all of us doing .NET or Java desktop applications is to set performance goals and regularly test during our development cycle. Then I think we will show Steven just how wrong he is.