Re: I'd appreciate your opinion(s)
- From: "Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 13 Feb 2008 11:49:12 -0500
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]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Fredo" <fredo@xxxxxxxxxxx> wrote in message
news:DZidne5GSK3tgS7anZ2dnUVZ_gidnZ2d@xxxxxxxxxxxxxxx
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.
"Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:eF5J8olbIHA.2268@xxxxxxxxxxxxxxxxxxxxxxx
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]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Arnie" <NoOne@xxxxxxxx> wrote in message
news:erNjnflbIHA.4684@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- I'd appreciate your opinion(s)
- From: Arnie
- Re: I'd appreciate your opinion(s)
- From: Nicholas Paldino [.NET/C# MVP]
- Re: I'd appreciate your opinion(s)
- From: Fredo
- I'd appreciate your opinion(s)
- Prev by Date: SelectionMode in a DataGridView
- Next by Date: Re: Validating user input using Sql DataType
- Previous by thread: Re: I'd appreciate your opinion(s)
- Next by thread: Xbap + database
- Index(es):
Relevant Pages
|
