Performance critical GUI application (windows,linux)

Question

All,

I've been tasked with updating a series of applications which are performance critical VB.NET apps that essentially just monitor and return networking statistics. I've only got three requirements: convert it to C#, make it fast, and make it stable

One caveat is that we "may" migrate from a .NET platform to linux "soon"

I will be responsible for maintaining these apps in the future so I'd like to do this right. I have decided to refactor these apps according to the MVP pattern so that I can properly unit test the hell out of this bad boy. But I was also thinking since I was using MVP that I could also do the computationally expensive stuff in native C/C++ code while the GUI would be done with .NET forms, or Qt or whatever.

questions:

1) does it make sense to do a GUI in winforms but the expensive stuff in native, unmanaged C/C++ ?

2) any recommendations for a good cross platform windowing kit that would fit for the scenario described above?

advTHANKSance

Answer 1

1) Premature optimization is evil. Implement your "expensive stuff" in C# and see if you need to refactor it. Or, at least set up a test that will allow you to determine this.

2) Yowch. Cross platform UI. I wouldn't put up with the "may" stuff. Nail the weasels down; how can you possibly make design decisions without knowing what you're designing? If you go with a pure .NET implementation, will they complain if you have to (at a minimum) refactor it to work in Mono? If you create it in Java, will they be annoyed that it looks ugly as hell and users complain that they can't find their .exe file amongst all those .jars?

Answer 2

For the first question, it is really hard to say if it would make sense as it would likely depend upon what sort of performance you need to be getting. I personally haven't seen any system wide slow downs due to the GUI in properly designed GUIs using WinForms so I don't see why it would should cause any problems, and in all likelihood it would make your life easier in regards to the GUI.

As for your second question, if you are going to be moving to another platform at some point - you want to take a look at the libraries that have been implemented by Mono (http://www.mono-project.com/Main_Page), this should also cover most of your needs in regards to cross platform windowing as it supports WinForms and GTK#.

Answer 3

No, it does not make sense to do the "expensive stuff" in C/C++. The potential (and most likely minor) performance improvements never, ever outweigh your productivity being an abject, sick joke when compared to C#. Really. It's not even close.

Read through this (and all posts referenced within): http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Answer 4

1) Not necessarily. I think it would be more correct to say that it's probably worthwhile writing your backend code in C++, regardless of the performance implications. Even though you can't tie your higher-ups down on the platform switch, it would be prudent of you to make preparations for that eventuality, since management types tend to change their mind alot without good reason (or warning); even if they decide not to switch now, that doesn't mean that they won't decide to switch six months from now. Writing your logic in C++ now, knowing that it's a possibility, though more difficult, may make your life significantly easier later.

2) Not really. There are "solutions" like wxWindows and GTK#, but often they're buggy, or difficult to get working properly, or they lack something important on one platform or another. They also usually lock you into a lowest-common-denominator UI (ie, general controls work fine but you can forget about ever doing something interesting -- WPF, for example -- with it). UIs are easy to write, so I think if you write your logic in something that's portable, it should be a trivial matter to knock together several platform-specific UIs.

Answer 5

You might want to look into using Mono. This is a open source version of .NET that runs on many plateforms...Linux,Mac, Solaris, Windows, etc..

Now about coding your expensive stuff in C/C++. Here's an article that does a very good job explaining the differences between C/C++ & C# performance.

Answer 6

thanks for all the great advice.

now, let me add in some other twists:

say that the apps are each individually fairly un-complex by modern standards, in terms of implementation. Each one is just a form with some buttons - but the buttons call some really expensive functions. (The View which is a Form sends a message to the Presenter which is just a class that wraps some C++ functions for you MVP pattern people).

In this case, the bulk of the work is done in the Presenter (C++ wrapper) while the form is just this empty shell. And again, let me emphasize, the C++ stuff is veerrrryyyy expensive. Would it make sense to do what I mentioned above? (.NET forms hiding heavy lifting C++)

Answer 7

Not an answer but a question...

Why are you converting a vb.net app to c#? There is no performance benefit to that surely?

Answer 8

And again, let me emphasize, the C++ stuff is veerrrryyyy expensive. Would it make sense to do what I mentioned above? (.NET forms hiding heavy lifting C++)

As noted before, I personally haven't noticed any system wide slow downs due to WinForms in applications written in both VB.NET and C#. However, if the application is truly performance intensive then you might notice a slight slow down if you wrote everything in C# due to it being complied into CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/). As such, writing the GUI in a language such as C# will likely make that part of the development a bit easier which would give you more time to work on the critical parts of the code. The only catch-22 here is might notice some slow downs due to the calls to the C/C++ code from the C# code; however, this is likely very unlikely.

Answer 9

I might be misunderstanding the issue, but if it is a network monitoring system, why isn't it written as a "dedicated" Windows service?

VB.NET shouldn't be much slower than C#. I'm not 100% certain if there is any big differences in the generated IL-code, but the only advantage (and justifiable reason to rewrite it in C#) I could think of (except that C# have a nicer syntax and some other goodies) is the use of unsafe code block that could speed things up a little.

Answer 10

First off, I would put some time into trying out a few VB.NET to C# converters. You're basically porting syntax, and there's no reason to do that by hand if you don't have to. Sure, you might have to clean up what comes out of the converter, but that's way better than a by-hand conversion.

Now, as for your questions:

1) does it make sense to do a GUI in winforms but the expensive stuff in native, unmanaged C/C++ ?

Not yet. Wait until you've done the conversion, and then find out where you're actually spending your time. There's no reason to jump into mixing C/C++ with C# until you find out that it's necessary. You may find that dropping into unsafe C# is sufficient. Even that may be unnecessary. You might just need to optimize algorithms. Find out what your bottlenecks are and then decide how to fix them.

2) any recommendations for a good cross platform windowing kit that would fit for the scenario described above?

I'd be looking into mono for sure. That's really the best you can do if you're going with C#. It's pretty much either mono or another rewrite in another language when/if you move to Linux.

Answer 11

1) does it make sense to do a GUI in winforms but the expensive stuff in native, unmanaged C/C++ ?

Most likely not. Unless you're communicating with a lot of other native C dlls or so on, C# is likely to be between 5% slower to 5% faster than C++ (std::string really kills you if you're using it)

2) any recommendations for a good cross platform windowing kit that would fit for the scenario described above?

If it's just some simple forms with buttons, mono will likely be able to run them unmodified. It's support for .NET WinForms is pretty good these days. It is however, butt ugly :-)

Answer 12

gtk-sharp is a pretty nice cross platform toolkit.

Answer 13

The c/c++ stuff may end up being a good idea, but right now YAGNI. Same with the Linux stuff. Ignore it, you ain't gonna need it until you need it. Keep it simple. Unit test the hell out of it, as you say. Get the code working and evolve the design from there.

Answer 14

I had similar dilemma some time back, while trying to find out a best way to develop a PC based H/W Testing tool (which obviously means "with UI options") that interacts with an embedded hardware (via PCMCIA interface).

The bottleneck was that the testing should run at maximum deviation of 10ms from the intended time specified by the tester.

E.g: If the tester creates the following test sequence:

1. Remotely activate the H/W
2. Wait for 50ms delay.
3. Read an H/W information.

the delay mentioned in step 2 should not be > 60ms.

I chose C++ WIN32 application as my back-end and VC++ 2005 Winform (.NET platform) for UI development. Detailed information on how to interface these two is available in msdn
I segregated the system like this:
In VC++ .NET:

1. UI to have complete information about the H/W (read via back-end application) and to control the H/W on demand. (Buttons, combo-box etc.. etc..)
2. UI to run time critical test sequences (as mentioned in the above example).
3. Gathering these information and building a stream (File-stream) in a Time-linear format (i.e, in the precise order of steps in which it has to be performed).
4. Triggering and hand-shaking mechanism (by redirecting standard input and standard output) with WIN32 back-end application. The common resources will be the File-streams.

In C++ WIN32:

1. Interpreting the Input File-Stream.
2. Interaction with H/W.
3. Gathering information from H/W and putting it in its Output File-Stream.
4. Indication of test completion to UI (via redirected standard output).

The complete system is up and running. It seems to be pretty stable. (Without the timing deviation mentioned above).
Note that, the testing PC we use is solely for the H/W Testing purpose (it had just the UI running on it, with no auto-updates, virus scan etc.. etc.. ).