C# - dotnet speed

Author

dotnet speed

MJH

2005-10-22, 6:58 pm

How does a dotnet app run (speedwise) vs. a C++ windows app? Does the
framework "interpreter" slow things down?

Bruce Wood

2005-10-23, 3:58 am

There is no interpreter. All .NET languages are JITted (just-in-time
compiled) at runtime.

That said, the C++ optimizer has always been (and still is) slightly
better than that for C#. It's nothing to do with interpreters: the
compiler simply produces slightly better code.

If you are using non-.NET C++ then you also have to factor in the JIT
time for C#: there is a one-time cost every time you call something for
the first time and the JITter has to compile it from IL (intermediate
language) into machine code.

Bruce Wood

2005-10-25, 7:01 pm

If the program runs for only a short time, and is run over and over
again, then the JIT compilation overhead will be more noticeable. If
you do loads of intense in-memory processing, then your choice of
programming language and platform may be more noticeable, with caveats
as follows.

Whether you should avoid .NET entirely depends very much upon what kind
of software you are writing, although I've seen people in the
newsgroups using .NET for even these applications, with claims that
there is little or no performance penalty.

When you say "interactive graphics program," if you mean your usual
program with a GUI, then you should definitely go .NET, and the
language doesn't matter. For my money, the only times you're likely to
see performance problems at the level that abandoning the .NET platform
might be worth considering are these:

o Programs with hard real-time deadlines. Here I'm talking about
communications equipment (telephone switches, etc) or controllers
(software to run medical equipment, stuff like that). The basic problem
here is that .NET languages, like Java, are garbage-collected, and the
GC can kick in at any moment and decide to recover memory. Not a good
thing if you're in the middle of giving a patient radiation therapy.
Although, as I said, I've seen programmers in these groups who say that
there are ways to control the GC and get around this.

o Programs that do intense in-memory processing. One example is ray
tracing: if your program is trying to produce the movie "Shrek" on the
fly then .NET may not be your platform, just because you can eke that
little extra bit of speed out of C++ compiled directly to machine code.

I find that most newbie programmers are vastly overconcerned with what
they call "efficiency" without really knowing what it is and how to go
about it. The best advice I can offer on the efficiency front is:

o Find out what others in the same field of programming are doing. If
everyone writing your kind of program is writing in C# or VB.NET,
there's probably a reason. If everyone writing your kind of program is
writing C++ and avoiding .NET, there's probably a reason for that, too.

o Come up with the best design you can, write the clearest,
easiest-to-understand code you can, then run it through a profiler. The
profiler will tell you where the bottlenecks are. Fix the bottlenecks
either by adjusting your design or improving your code. Repeat until
satisfied. Absolutely do not start out tweaking code throughout your
program before you know where the bottlenecks are, unless you have a
decade or more of programming experience and already know what
constructs are inefficient in what contexts.

For 99.9% of the software out there, efficiency comes from good design,
not code tweaking or switching platforms. An inefficient design written
in C++ with hand-tweaked code is still loads slower than an efficient
design written in C# on .NET, as a general rule. The big problem with
junior programmers is that they tend to come up with poor designs and
then spend their time fretting over whether i++ executes faster than i
+= 1 in areas of the program that aren't even the problem.

Sponsored Links