C++ vs JAVA

Well the language report is up.

http://www.ipd.uka.de/EIR/otherwork/jccpprt_computer2000.pdf

 

Oh, this sounds dreadfully familiar...
But at last, JBuilder 9 seems to have finally gotten much better in this respect. I wouldn't say it's gone for good, but I only had such a memory leak once in the last three months, usually it stays at ~100MB after some time.

 

In all fairness, I should note that .NET Studio 2003 has a tendency to suck up a good chunk of memory as well.

But in terms of overall performance, Microsoft's IDE is significantly more "snappy" than any/all JBuilder IDE's, including JBuilder 9.

I really wish it were possible to have a "Developer Studio" esque IDE for Java. I know some people think that everything that is Microsoft totally sucks, but I happen to think they have a clue in how/what an IDE should do/be, and how to develop the things with performance in mind.

 

re ms IDE's snappiness -- how about VC6's IDE spawning the cc at a priority sufficiently high as to effectively prevent the user from doing anything else? yes, there's a patch to alleviate that, no, it's not in the standard distributive. try that on a serious, 50+projects-fat workspace, then we shall talk about snappiness (first rule of multi-tasking environments -- thou shalt spawn computationally-heavy, non-RT tasks at _lower_tha_normal_ priority -- seems like msvc's engineers slept through their early univ courses).

from my personal experience, the IDEs i've felt most comfortable with are metrowerk's - those guys do know how to write software for professional pursposes (to the point of such small goodies like spawning multple cc's at users discretion on SMP systems)

 

There's a history behind that. Prior to Visual C++ 5.0, the Microsoft compiler was slower in compilation time to Borland C++ (but the compiled code was ran faster), and produced compiled code that executed slower than Watcom 10.5. Watcom was the king of optimized compilers for a while. Microsoft decided that they wanted to be #1 on all fronts, including having the smallest code, with VC 5.0. This was achieved by using many tricks like you mention (including turning off RTTI by default). I guess they figure that when you're building, it's a good time to visit the kitchen .

The point is becoming less important now though. With C# and .NET taking over for C++ for mainstream Windows applications, C++ performance is becoming decreasingly important (though it will never go away completely).

 

darkblu,

Hard to really make a 1-to-1 comparison here, but our current C# application contains around 20 or so projects, consisting of about 150,000 lines of source. This is a combination of both C#, as well as C++.

Other than the amount of time it takes the IDE to communicate with the VSS server, it's not slow at all.

I do know where you're coming from, however. I used to work at a place that had a large C++ project that would take forever and a day just to initialize, due to all the various projects within the workspace.

Between the IDE and the tools, I would have to rate my satisfaction with .NET Studio 2003 very high. There aren't a heck of a lot of things I wish it would do or do better.

 

Dear forum users, Jaba must die.

Java's performance and memory usage are a joke.
Loosing by a factor of 2-5x in speed is no option IMHO. That's just a way to sell "new" software, which runs so slow that one must buy new hardware.
Java is supposed to be multi-platform. Supposed. But C/C++ IS multiplatform.
Dear forum users, Jaba must die.

 

Dear forum users, Jaba must die.

But why wouldn't work? Because the very nature of C/C++ or because you'll use some specific win32 library/API ?

Dear forum users, Jaba must die.

 

Nice to see Sun taking back things from C#. I really thought C# was "the right Java" when I first read about it. Haven't programmed in it yet, but "Inside C#" is on its way.

BTW, for Java development I always IBM's Visual Age for Java (dead now). I still open it to do quick checks of things, because it's possible to just type code in its scratchpad and have it executed. (Although if I don't manage to get my Windows 2000 back, I might not reinstall it, because I'm no longer progamming in Java.)

 

Unfortunately, there's a _very_ large performance penalty associated with boxing/unboxing. Slashdot had a link tonight (pure coincidence) to a guy that published a paper comparing a variety of different things, with respect to C/C++/Java/C#. You can clearly see just how costly it is for both Java/C#.

Don't get me wrong. It's definitely a _good_ thing to have, but you have to be careful. I ended up having to write, in effect, a C# interface to the C Borland Database Engine (BDE) library, and I'm 100% confident that the area where I lose a lot of performance is in boxing/unboxing different data types.

 

Basically, regardless of the language, creating an object is likely to be one of the most expensive operations. It is best to avoid it by having some caching mechanism. This should be a fairly simple optimisation done by the compiler in a number of cases.

 

Yes. Object creation seems to be one of the larger performance impact areas in Java, most of it dealing with reference counting schemes and permission checks during virtual-function invocations. During my work on the ORB of our J2EE App Server, I gained a surprising amount of performance in the marshalling code by keeping pre-canned objects around to use for boxing/unboxing. Somewhat surprising was finding that cloning of the pre-canned objects can be significantly faster that just newing one up. Provided with the right monitoring tools, one can learn all sorts of nuances and quirks of the language implementation.

 

The other thing that's really bad, performance wise, is reflection. I really love what reflection brings to the table, but I have also seen the downside as well.

When used sparingly, and certainly, in places that don't interrupt the main UI thread/messagepump/etc., they're definitely kool.

 

I've heard -- and I agree with it -- is in most cases, reflection, is the lazy/bad coders case statement.

 

I'll speak on behalf of C#, though this isn't much different from Java.

When you have a type system similar to C#, there are a lot of things you can learn about a given data type. In fact, you can learn so much about it, you would never have to have ever seen/known about the type in advance to learn everything you need to know about it.

What I just described is what reflection can do for you. Reflection is the ability to, in a sense, query a type about its capabilities, and even call methods.

As an example, in C#, all objects provide the "GetType()" function. So, we might have something like this (assume var is just some object):

System.Type t = var.GetType();

OK, now we have the type. With the type, we can now query it...Properties is a member Property (C# supports true properties, Java does not) of class Type, and this essentially returns an array of PropertyInfo objects.

foreach (PropertyInfo pi in t.Properties)
{
Console.WriteLine("Property Name: " + pi.Name;
}

As I said, there are also mechanisms where I can use reflection to actually invoke methods contained within objects.

Reflection can ve very powerful, but as you might imagine, is not fast at all. I have used it in places that make some things easier, but you definitely have to make sure that performance is not critical.