moving to C# from VC++ 6 - how does app speed compare?

[mt]

Hi,

W H A T
I am considering moving my windows app written in Visual C++ 6.0 to C# .NET.


Q U E S T I O N
I was wondering if application speed will be a problem in .NET when compared
to a VC++6? Am I going to take a big performance hit?


W H Y
My main reason for doing this is to simplify the building of the app's front
end GUI. It seems that windows and controls construction is a WHOLE lot
easier in C# than it is with MFC? But I am totally new to .NET and C#, so I
may be wrong about this?


M Y A P P
My application is a single window SDI. It receives it's input via a network
ActiveX control, but it's just a string of characters really. It then does
some heavy string/character parsing, stores everything in arrays and then
prints text to the window. So the app's basic requiremts are :-

- parse strings of characters quickly
- store large numbers strings in memory efficiently and be able to get to
each string quickly
- repaint the interface when the user scrolls
- that's it

Thanks for any feedback.

Mike

 

[Roy Fine]

mt,

Doesn't sound as if your program uses a lot of MFC - so improvements in the
GUI design and implementation will be minimal.

What do you use for the string manipulations in the current design? Is it
STL, or the MFC CString class, or brute force using char * and CRT
functions?

If your app is highly tuned and you are using a mixture of these (STL for
storage, CString for display, and CRT functions for manipulations) then you
can expect to take a serious performance hit at first, partially due to the
learning curve, and partially due to the storage inefficiencies of the C#
string class.

That said, the performance delta may likely be unnoticeable by typical
users. For instance, your program may spend 10% of the wall clock time
manipulating and parsing strings, 55% of the time fetching data from the
network, and 35% of the time formatting, populating controls, and managing
the display.

After converting to C#, if you experience a 50% increase in the time to do
the manipulating and parsing, the precentages would be 14%, 52%, and 43%.

The things that C# does not do as well as native C/C++ programming are
typically not related to the "long pole in this tent"..

regards
roy fine

 

[Rob Teixeira [MVP]]

inline:

Hi,

W H A T
I am considering moving my windows app written in Visual C++ 6.0 to C# ..NET.


Q U E S T I O N
I was wondering if application speed will be a problem in .NET when compared
to a VC++6? Am I going to take a big performance hit?

That seriously depends on what the code is doing. Without more details (and
even with more details), the only way to tell may be to perf the two
versions.

W H Y
My main reason for doing this is to simplify the building of the app's front
end GUI. It seems that windows and controls construction is a WHOLE lot
easier in C# than it is with MFC? But I am totally new to .NET and C#, so I
may be wrong about this?

Depends I guess. I know somebody who coded in MFC for YEARS, and he's quite
comfortable with it. Took him a while to get his head wrapped around C# and
the Framework. You have the tendancy to look for things using the same
model, and get hung up when you have to solve the problem differently.
Personally, I hated using MFC, so I consider C# to be much easier myself (in
the area of building GUIs anyway).

M Y A P P
My application is a single window SDI. It receives it's input via a network
ActiveX control, but it's just a string of characters really. It then does
some heavy string/character parsing, stores everything in arrays and then
prints text to the window. So the app's basic requiremts are :-

- parse strings of characters quickly
- store large numbers strings in memory efficiently and be able to get to
each string quickly
- repaint the interface when the user scrolls
- that's it

So this is kind of like a network messaging thing? Hm, well, again this
going to depend. C#'s string manipulation might be a bit slower than using
brute force buffer manipulation in C. However, C# also supports pointers, so
it's possible you can work around some of these issues. On the other hand,
if the string manipulation is part of the scrolling window's job, there is
also the possibility of creating an ActiveX control using C++ and using it
on your C# SDI forms if you are really paranoid about speed. There are a lot
of variables and different ways to approach this. It's hard to say until you
try.

-Rob Teixeira [MVP]

 

[mt]

Roy,

Thanks for the feedback.

Mike

mt,

Doesn't sound as if your program uses a lot of MFC - so improvements in the
GUI design and implementation will be minimal.

What do you use for the string manipulations in the current design? Is it
STL, or the MFC CString class, or brute force using char * and CRT
functions?

If your app is highly tuned and you are using a mixture of these (STL for
storage, CString for display, and CRT functions for manipulations) then you
can expect to take a serious performance hit at first, partially due to the
learning curve, and partially due to the storage inefficiencies of the C#
string class.

That said, the performance delta may likely be unnoticeable by typical
users. For instance, your program may spend 10% of the wall clock time
manipulating and parsing strings, 55% of the time fetching data from the
network, and 35% of the time formatting, populating controls, and managing
the display.

After converting to C#, if you experience a 50% increase in the time to do
the manipulating and parsing, the precentages would be 14%, 52%, and 43%.

The things that C# does not do as well as native C/C++ programming are
typically not related to the "long pole in this tent"..

regards
roy fine





so

 

[miket]

Rob,

Thanks for the feedback.

I think that I will go the ActiveX route and turn my C++ code into a
control and have the C# do all the interface work.

I don't know how to build such an application (C# front end - C++
backend) so I guess I will search for some examples. If you have any
further pointers on this I would be glad to hear from you.

Thanks

Mike