I'd appreciate your opinion(s)

[Arnie]

Hi all,

If this is the wrong group, please redirect me.

I/we do native C++ and know next to nothing about C#/.NET or Java/J2EE.
We're looking at doing at least a partial rewrite of our product. It
contains about 200 EXE and DLL files - some written in Borland C++ Builder
and some in VC++ 8. We'll be upgrading to VC++ 9 shortly for our VC++ apps.

All of our apps use either SQL Server, Oracle or DB2 for a DB server. We
have three classes of apps in the product. I'd like your opinions on which,
if any are suitable for C# or Java (I realize most people here will be kinda
biased toward C#).

Realtime - It may process thousands of requests per second. It has to look
up info in the DB, process it and return it. The expected response time is
< 1 second. Once it's up and running it doesn't do a lot of memory
allocation.

Console or 'batch' apps - Many of these are very memory intensive. We have
to use the /3GB and /LARGEADDRESSAWARE options at our larger customer sites.
Typically, there is a lot of memory allocation and deallocation going on.

Client apps - They provide the interactive GUI to our users. They are fat
clients. There is some code sharing between the client and console apps
both at the module and DLL levels. We have not yet made a decision to go
with a browser-based or 'smart' client.

I know this isn't much to go on but I'd appreciate any input I can get.
BTW, the rewrite wasn't my idea ;-)

Thanks,
- Arnie

 

[Nicholas Paldino [.NET/C# MVP]]

Arnie,

When it comes to all of the apps except for ones defined in the Realtime
section, then I would say that .NET or Java are perfectly fine for this kind
of development. This would also provide an opportuntity to see where you
can consolidate code, and firm up your component design.

Java and .NET can both do "smart" clients, fat clients, or web-based
apps. You just have to see what you are most comfortable with in terms of
techology and tools and then go with that.

Now, when it comes to the Realtime category of apps, I believe that .NET
could process thousands of requests a second (of course, thousands can be
anywhere from 2000 up to 999,000, at which point one would say "millions",
so there is a large range there), but typically, .NET and Java are not meant
for this kind of work. Of course, I am assuming that by realtime you mean
your apps are meant for controller systems where the response must be in a
predetermined amount of time (and not because someone wants it that way, but
because failure to do so usually has a catostrophic, or at the least,
severely adverse effect, like controlling a nuclear power plant, a
pacemaker, or something of that sort).

If your app doesn't have this kind of responsibility, then I would say
that "realtime" is a misnomer, and that you could definitely use Java or
..NET for this class of apps, but the only way to be sure would be to try it
out, and see what kind of performance you get, and whether or not it
satisfies your needs.

 

[Fredo]

I agree with what Nicholas said. On top of that, I would add that,
performance-wise, .NET is pretty good. I do a lot of graphics stuff in .NET,
including some very math-intensive analysis and find the performance to be
reasonably close to native code. Close enough that I'm not concerned with
rewriting any of it in managed code.

For your memory heavy stuff, .NET definitely packs on a bit at startup, but
probably not enough to make a difference with the space you're using. You
might have to jump through some hoops to manage the memory (like
periodically forcing garbage collection), but it shouldn't be too bad.

Arnie,

When it comes to all of the apps except for ones defined in the
Realtime section, then I would say that .NET or Java are perfectly fine
for this kind of development. This would also provide an opportuntity to
see where you can consolidate code, and firm up your component design.

Java and .NET can both do "smart" clients, fat clients, or web-based
apps. You just have to see what you are most comfortable with in terms of
techology and tools and then go with that.

Now, when it comes to the Realtime category of apps, I believe that
.NET could process thousands of requests a second (of course, thousands
can be anywhere from 2000 up to 999,000, at which point one would say
"millions", so there is a large range there), but typically, .NET and Java
are not meant for this kind of work. Of course, I am assuming that by
realtime you mean your apps are meant for controller systems where the
response must be in a predetermined amount of time (and not because
someone wants it that way, but because failure to do so usually has a
catostrophic, or at the least, severely adverse effect, like controlling a
nuclear power plant, a pacemaker, or something of that sort).

If your app doesn't have this kind of responsibility, then I would say
that "realtime" is a misnomer, and that you could definitely use Java or
.NET for this class of apps, but the only way to be sure would be to try
it out, and see what kind of performance you get, and whether or not it
satisfies your needs.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi all,

If this is the wrong group, please redirect me.

I/we do native C++ and know next to nothing about C#/.NET or Java/J2EE.
We're looking at doing at least a partial rewrite of our product. It
contains about 200 EXE and DLL files - some written in Borland C++
Builder and some in VC++ 8. We'll be upgrading to VC++ 9 shortly for our
VC++ apps.

All of our apps use either SQL Server, Oracle or DB2 for a DB server. We
have three classes of apps in the product. I'd like your opinions on
which, if any are suitable for C# or Java (I realize most people here
will be kinda biased toward C#).

Realtime - It may process thousands of requests per second. It has to
look up info in the DB, process it and return it. The expected response
time is < 1 second. Once it's up and running it doesn't do a lot of
memory allocation.

Console or 'batch' apps - Many of these are very memory intensive. We
have to use the /3GB and /LARGEADDRESSAWARE options at our larger
customer sites. Typically, there is a lot of memory allocation and
deallocation going on.

Client apps - They provide the interactive GUI to our users. They are
fat clients. There is some code sharing between the client and console
apps both at the module and DLL levels. We have not yet made a decision
to go with a browser-based or 'smart' client.

I know this isn't much to go on but I'd appreciate any input I can get.
BTW, the rewrite wasn't my idea ;-)

Thanks,
- Arnie

 

[Nicholas Paldino [.NET/C# MVP]]

I don't know that I would condone a force of a GC, as that's usually a
bad idea. The fact that so much memory is used really doesn't mean you
should be more aggressive in provoking GCs. Rather, the memory consumption
might be totally different, given how the code is translated.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I agree with what Nicholas said. On top of that, I would add that,
performance-wise, .NET is pretty good. I do a lot of graphics stuff in
.NET, including some very math-intensive analysis and find the performance
to be reasonably close to native code. Close enough that I'm not concerned
with rewriting any of it in managed code.

For your memory heavy stuff, .NET definitely packs on a bit at startup,
but probably not enough to make a difference with the space you're using.
You might have to jump through some hoops to manage the memory (like
periodically forcing garbage collection), but it shouldn't be too bad.

Arnie,

When it comes to all of the apps except for ones defined in the
Realtime section, then I would say that .NET or Java are perfectly fine
for this kind of development. This would also provide an opportuntity to
see where you can consolidate code, and firm up your component design.

Java and .NET can both do "smart" clients, fat clients, or web-based
apps. You just have to see what you are most comfortable with in terms
of techology and tools and then go with that.

Now, when it comes to the Realtime category of apps, I believe that
.NET could process thousands of requests a second (of course, thousands
can be anywhere from 2000 up to 999,000, at which point one would say
"millions", so there is a large range there), but typically, .NET and
Java are not meant for this kind of work. Of course, I am assuming that
by realtime you mean your apps are meant for controller systems where the
response must be in a predetermined amount of time (and not because
someone wants it that way, but because failure to do so usually has a
catostrophic, or at the least, severely adverse effect, like controlling
a nuclear power plant, a pacemaker, or something of that sort).

If your app doesn't have this kind of responsibility, then I would say
that "realtime" is a misnomer, and that you could definitely use Java or
.NET for this class of apps, but the only way to be sure would be to try
it out, and see what kind of performance you get, and whether or not it
satisfies your needs.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi all,

If this is the wrong group, please redirect me.

I/we do native C++ and know next to nothing about C#/.NET or Java/J2EE.
We're looking at doing at least a partial rewrite of our product. It
contains about 200 EXE and DLL files - some written in Borland C++
Builder and some in VC++ 8. We'll be upgrading to VC++ 9 shortly for
our VC++ apps.

All of our apps use either SQL Server, Oracle or DB2 for a DB server.
We have three classes of apps in the product. I'd like your opinions on
which, if any are suitable for C# or Java (I realize most people here
will be kinda biased toward C#).

Realtime - It may process thousands of requests per second. It has to
look up info in the DB, process it and return it. The expected response
time is < 1 second. Once it's up and running it doesn't do a lot of
memory allocation.

Console or 'batch' apps - Many of these are very memory intensive. We
have to use the /3GB and /LARGEADDRESSAWARE options at our larger
customer sites. Typically, there is a lot of memory allocation and
deallocation going on.

Client apps - They provide the interactive GUI to our users. They are
fat clients. There is some code sharing between the client and console
apps both at the module and DLL levels. We have not yet made a decision
to go with a browser-based or 'smart' client.

I know this isn't much to go on but I'd appreciate any input I can get.
BTW, the rewrite wasn't my idea ;-)

Thanks,
- Arnie