C++ vs. C# (new to windows programming)...

[Volker Hetzer]

Hi!
After messing around for some time with Tcl/Tk and VBScript,
we've finally reached the point where we need to put some speed
into our applications.

So, our typical application looks like this.
We've got this huge CAD tool, called Mentor Expedition, which
understands VBScript and JScript and offer an ActiveX-Interface
for Automation.

What we typically do is we have an application Gui which is
separate from the tool (Tcl/Tk), then connects to the tool and
accesses Automation objects.
This incurs a big overhead and limits performance to about 100
calls per second. This is way to slow.

We then did a few VBscript components and let that Mentor-Tool
run those via VBscript. That got us quite a speedup for as long
as we limited ourselves to getting data and iterating over
collections.

Now we are at a point where the VBScript needs to do some "real"
calculations too, like geometric transformations .

Therefore we are thinking of introducing a new animal into our
language zoo for the real high speed stuff.

The idea is to put the performance critical parts into a COM
component or, in fact into anything that can be loaded via the VBscript
createobject call, gets the Handle of some big Automation object,
runs in-process, maybe does a bulk insert into an oracle database
on the side (using oracle ole db) and can return complex objects
back to VBScript, like dictionaries or other self defined collections.
We are not really interested in Gui's, more in building blocks.

I've got a bit of experience in C++ from about ten years ago
on Linux.

Right now I'm tending a bit towards C++ for the speed and the
deterministic destructor calls, but I am absolutely glueless about
Windows programming in general, except for VBScript command
line tools.

What would you suggest?

Lots of Greetings and Thanks!
Volker

[Volker Hetzer]

Israel schrieb:

With that being said there should be no reason why mathematical
operations in C++ should be any faster than in C# unless you are
somehow exploiting some mmx routines that C# *may* not support. Ok, what I meant was self contained code that just needs the processor
and no network connections and such. Loops, recursion, searches,
trigonometry too. I agree that things like trigonometry are probably
provided by a fast library, regardless of the language.
The
issues you need to concern yourself with are the communications; making
a lot of consecutive remoting calls (cross process) will incur more
timing overhead Yes, from my timings it's about factor 20 in speed. (VBScript remote
versus VBScript in-process)
One requirement therefore is that our extensions have to run in-process.
For the tool we are extending that means something VBScript can
access using createobject. Which seems to be COM only, either as dll
or as .net assembly(?) with a com wrapper.

Personally I would suggest trying C# vs. C++, especially if you're
not proficient with windows programming in C++. That's what we will do.
I've noticed a very large boost in productivity since switching over
to mainly C#. Where productivity is more important than speed (i.e. for prototypes
and first versions) we use Tcl/Tk here.

In summary, you may hit different performance issues with C# vs. C++
but there should be a solution in C# that achieves the desired
performance. In terms of a learning curve using C# will be at least an
order of power easier than C++ to produce and maintain viable code.
You should do diligence and prototype the anticipated interactions with
your application using a C# application and if you run into performance
issues there are plenty of google groups members that will probably
have good suggestions to solve them. Right now we are also doing a two stage approach. Prototypes are usually a
combination of Tcl/Tk and VBScript and when those have been used for a while
(we do inhouse programming) and requirements are moderately stable we look
at performance bottlenecks and want to do a proper design for version II,
for which we are selecting the tools now. It will also be a layered architecture,
using several programming languages. I can well imagine a combination of
Tcl or VBScript and a small part written in C# or C++, depending on what
profiling suggests.

Btw, here it's not so much about "fast enough" yet.
"Fast enough" in our context would mean less than about 2s. :-)
Right now we have runtimes of 20min and more. With typically six layout
engineers using those programs several times per day, every saved minute
translates directly into productivity at a place where we currently have
a bottleneck.
Side note:
When I first started using C# the non-deterministic destructors really
bothered me because I had grown accustomed to implementing solutions
using them like synchronization and opening files etc. It hasn't
taken me too long to get used to designing things a little differently
and utilizing try..catch..fin ally blocks a lot more or using
IDisposable.

After reading up about this I think I can agree with that. The C# way
has advantages (I can control the order of destruction) and disad-
vantages (the caller must be more careful) but I think both lead to
less problems than manual resource management.

Lots of Greetings!
Volker