Tim did say that architects and developers should consider what
languages/platforms are best for their needs. He did state that .NET isn't
really for real-time applications.

Performance can be better by following certain guidelines. If you leave all
your memory to be collected by the GC you will suffer performance penalties
at some point. If you free your memory - perhaps by following the disposable
pattern for managed memory as well as native handles - you can
deterministically free memory so that the GC doesn't lock the threads while
collecting later.

Rico Mariani's blog at http://blogs.msdn.com/ricom/default.aspx is a good
place to read about performance, not just for managed code but native as
well. So is Raymond Chen's blog at
http://blogs.msdn.com/oldnewthing/default.aspx.

I would say if your program has a 1 second latency it's probably due to poor
design (of the application itself) or extremely busy CPU already, than to
the GC.
I would recomend you start really investigate the cause of the problem
instead of randomly targetting the GC.

For example providing a code sample demonstrating your problem would be a
first step toward valuable & hinsightful feedback.

In case it's the GC, I will be .. amazed.
But well, in this case let's imagine the kind of scenario where the CG could
do that.
As some other poster said, he was able to alloc / GC more than 40.000.000
(40 millions) Object per second without trouble.

So I doubt it's the sheer number of object which cause the GC trouble.
Maybe it's the Dispose() method?
Dispose() should be quick, do you have lengthy operation (such as
Transaction.Commit()) in the Dispose() code of your objects?

Also to answer an other question: what kind of application needs .NET to be
developped.
Well I would say I have yet to see a case where .NET didn't improve
dramatically devlopment time and program reliability while, at the same
time, keeping comparable performance.
So it's probably a good solution for any developer on earth but you ;-)

Solid application design requires a logical, systems oriented approach to
development. Perhaps if you weren't so loaded with emotion and anti
Microsoft sentiment you could determine the actual reasons for your
application not meeting its requirement definitions rather than spouting off
like a trantrum throwing child.

It might well be that the .NET framework is not for your project but more
often than not these crys of it being a buggy, unreliable, non performant
platform are in fact more indicative of piss poor application design and/or
development lacking in a "best practises" approach.

Perhaps if you learn to approach your projects, and your posts for that
matter, with a little more balance, maturity and professionalism you may not
find yourself having either choosen the wrong tool for the job nor blaming
it when you cant use it correctly.

Ian

I have a real-time automation server written on .NET. Responding time is
about 300ms. Works fine.

Yes, that's part of the definition of a real time application.

If you want to develop a true real time application, they would recommend
nor .NET neither Windows. Windows is not a real time OS because, among
other things, it uses pre-emptive multi tasking, hence preventing you to
know how long will a task in your program take. To do real time
application, you must use a real time OS to begin with. Real time
applications are a whole different world than desktop or server consumer
applications.

At first, I was under the assumption you really wanted to get an answer. Now,
I am more inclined to think you are a troll. If you are not, at least step
off the high horse and start responding in a civil manner.

Ahem,

I have not had any issues with .NET when writing applications in C#.  .Net
2.0 beta performance has been an issue from time to time for me, but hey,
it's in Beta and I expect the final release to be good.

The person who started this thread really needs to re-evaluate what they are
saying and look at the code they are trying to produce before ranting on
about Microsoft sucking.

Paul

First, Chris is mistaken. C# is as powerful as C++, if you know how to use
it. And, in fact, you can use C++ and C, and even Assembler with C# any time
you need to (and I have done this myself, so I know what I'm talking about).

Second, "suckier" is a characterization, not an argument. It means nothing,
other than implying that you have a negative opinion of it. If you are a
programmer, you should know the difference between logic and rhetoric. If
you do not know the difference, you are a "sucky" programmer.

Third, the .Net platform, like any other software, was developed to fulfill
certain requirements. It fulfills them beautifully. Among these requirements
are cross-platform compatibilty, cross-language compatibility, better
avoidance of memory leaks in complex applications, and productivity.

The cross-platform compatibilty aspect is achieved in the same way that Java
achieves it: The software is compiled to a byte code that is
non-machine-specific, and compiled to native machine language at runtime.
However, this introduces a latency in run-time compilation, which has been a
long-time problem with Java. The .Net platform minimizes this by a
sophisticated caching mechanism, which makes it run faster than Java
overall. The proof that the .Net platform is cross-platform-compatible can
be seen in the Mono project (http://www.mono-project.com/Main_Page), which
is an open-source project for a number of different OS versions of the .Net
platform.

Cross-language compatibility is one thing Java has never had. This enables
developers to write .Net code in virtually any language of their choosing.
There are more .Net languages than there are for any other platform. Period.

Avoidance of memory leaks is achieved primarily through Garbage Collection.
While you seem to think that Garbage Collection is a bad thing, it happens
to be quite common to object-oriented technologies, including Java, Perl,
Lisp, Smalltalk, Flash MX, and quite a few others (see
http://www.memorymanagement.org/articles/lang.html for a more complete, but
not comprehensive list). Comparing apples to apples, the .Net platform
employs the most up-to-date, fastest, and most powerful Garbage Collection
available today. No other technology that uses GC has the quality that the
.Net platform has. You may benefit from reading the following FAQ about
Garbage Collection: http://www.iecc.com/gclist/GC-faq.html. You can find
much more complete information about the subject at
http://www.memorymanagement.org/.

Productivity is the final point I wish to discuss, as you think that C# is
"suckier than c++". C# is designed along the same lines, and to fulfill the
same requirements as C++, and C before that. It is concise. It is
strongly-typed. And it is easier to use than C++, with a more concise
syntax. It includes constructs that are designed to enable the developer to
spend less time writing code, which enhances productivity, such as
NameSpaces, Attributes, delegates, and so on. In addition, the .Net 2.0
platform introduces several new constructs, the most notable is Generics. C#
is less cryptic than C++ as well. It is important to note that C++ is over
10 years old, and was developed as one of the first object-oriented
languages. Programming has come a long way since then, and programming
languages and technologies have had to adapt. Fortunately, C is extensible.
And while the extension of C known as C++ was a good start, 10 or so years
ago, C# is the next logical extension of C, enabling programmers to write
much larger applications in a much shorter time.

The bottom line of all this is, ignorance may be bliss, but it doesn't pay
the bills. You sound like a young, lazy guy who doesn't want to learn and
adapt. Well, I'm almost 50, and I hope I never stop learning. Knowledge is
power. Yes, it's work, but if you don't like work, you shouldn't be a
programmer. If you don't enjoy solving new problems, you won't get far in
this business. And if you don't love programming, don't quit your day job.
Real-world programming is a pain in the butt, but it's a love-hate
relationship for those of us who are successful at it, and I wouldn't do
anything else if I had the chance. Yes, you bleed a bit on the cutting edge,
but what a view!

That doesn't mean that C# is a bad language or that it's less powerful
than C++. I'd actually argue that C# is just as powerful, but far more
productive.

What makes software written in C# unsuitable for "real time
applications" isn't the language--it's the platform. .NET is not a
platform suitable for developing real-time applications.

As for why they did that with C#? Well, first off, C# is far more
NATIVELY object-oriented than C++. Originally, C++ was an extension of
C, and came with lots of baggage from C (manual memory allocation and
cleanup, for one). C# is a brand new language, designed from the ground
up to be object-oriented. It isn't an existing language that had
object-oriented features strapped on top of it. Its primary similarity
to C and C++ is the syntax, but that's about it.

Also, you have to place all this stuff in its proper context.
Conspiracy theorists might somewhat justifiably draw the conclusion
that Microsoft developed C# because it got slapped on the wrists for
messing with Java. When designing C#, Microsoft didn't have to abide by
Sun's rules about what it could and could not add to the language. So
they built an entirely new language, designed to be object-oriented
from the ground up, using C-style syntax, but incorporating many of the
features that made VB such a productivity boon. The pervasive
familiarity with the C-style syntax makes it appealing to a *very*
broad number of users (C, C++, and Java programmers at the least),
while the productivity enhancements from VB make it likely that many VB
developers will take a look at it.

I think that if I was Billy Boy, I'd see that as a really good thing,
and more than enough justification for creating the language. And then,
I could look like a really good guy if I made them standards.