How does C-Sharp Perform in Large Desktop Applications?

[Bruce]

Currently our desktop application is a large VC++ 7.1, Unmanaged, MFC
application.

We are going to be re-architecting our application and we are considering
rewriting it using C-Sharp.

So far, we have written a few pieces of our program in C# that get called
through a managed DLL. But they are used infrequently so the impact on
performance has been minimal. We wrote these pieces in C# because it was
easier to do in the short amount of time we had available. But our
experience with these components has been that the C# stuff tends to be much
more sluggish than the unmanaged MFC code in the rest of the application.

Has anyone out there had experience writing or converting a large desktop
application from MFC to C#?

Performance is a big issue with our users, so we are very concerned about
keeping our application responsive for the users.

--
Thanks,
Bruce

[jeremiah johnson]

Bruce wrote:

Currently our desktop application is a large VC++ 7.1, Unmanaged, MFC
application.

We are going to be re-architecting our application and we are considering
rewriting it using C-Sharp.

So far, we have written a few pieces of our program in C# that get called
through a managed DLL. But they are used infrequently so the impact on
performance has been minimal. We wrote these pieces in C# because it was
easier to do in the short amount of time we had available. But our
experience with these components has been that the C# stuff tends to be much
more sluggish than the unmanaged MFC code in the rest of the application.

Has anyone out there had experience writing or converting a large desktop
application from MFC to C#?

Performance is a big issue with our users, so we are very concerned about
keeping our application responsive for the users.

for most things it is very similar to C++ programs in my experience.
Most of the slowdown appears when you start the program. once the
program is running I don't think you'd notice much of a difference,
especially since it is a gui app and would be waiting on the user to do
something a majority of the time.

i think you'll be pleased with C# performance, especially C# 2.0. (3.0
by ECMA spec standard)

jeremiah

[Christoph Nahr]

On Thu, 8 Dec 2005 17:21:55 -0600, "Bruce" <bw*****@nospam.nospam>
wrote:

So far, we have written a few pieces of our program in C# that get called
through a managed DLL. But they are used infrequently so the impact on
performance has been minimal. We wrote these pieces in C# because it was
easier to do in the short amount of time we had available. But our
experience with these components has been that the C# stuff tends to be much
more sluggish than the unmanaged MFC code in the rest of the application.

This is not representative of C# performance overall.

When you call into a managed DLL from unmanaged code, all calls must
be marshalled to compensate for the different storage of variables in
memory. Depending on your calls, data structures such as strings and
arrays will have to be copied back and forth.

That doesn't happen when you run a program entirely written in C#
(unless you extensively call back to native code, then you'll have the
same issues!). Pure C# is about 80% as fast as C++ in my experience.
--
http://www.kynosarges.de

[Christoph Nahr]

Also, you definitely should be using version 2.0 of C# and the .NET
Framework. Generic collections are a huge help for big desktop apps,
both in terms of development and performance, and there are some nice
enhancements to Windows Forms that you wouldn't want to miss.
--
http://www.kynosarges.de

[Olaf Baeyens]

> Has anyone out there had experience writing or converting a large desktop

application from MFC to C#?

Performance is a big issue with our users, so we are very concerned about
keeping our application responsive for the users.

I am creating software that does image processing using using a mixture of
C# and managed+unmanaged C++.
Tests suggest that some functions will be faster others will be slower so it
is hard to predict the performance of the code.

One thing I would advice is to reduce jumping from managed to unmanaged and
the reverse as possible.
If you need some processing in a loop called form C# and uses functions in
unmanaged C++ then it is better to create a C++ class that performs this
loop, so this way no more transition speed loss.

Currently I am using C# for user interface, and unmanaged C++ for fast
processing.
C# because I can program much faster than the managed C++ code, and is far
more readable.

Tests here suggests about 5% speed loss average but I do develop my software
7 times faster, because it compiles much faster if I use C#.

One thing that might be important is that if you create pure C# code, then
you can flag it such a way that it runs as 64 bit on a 64 bit OS machine and
that same executable will run 32 bit on a 32 bit OS. Only one executable for
both platform!

There is a delay if you start up a program and when you start a function
that the has not been loaded before. This is because the code gets compiled
to native processor code, once it is loaded then it is running nearly as
fast as a normal C++ program. But this loading might give an impression that
C# programs are slower.

I hope this helps?