Scribd
Upload
5 views

Java VS C or C++

The document discusses the performance of Java compared to C/C++. It notes that Java can be faster than C/C++ for some applications and discusses how the Java virtual machine and garbage collection contribute to performance. It also talks about issues with assumptions made by some Java libraries.

Uploaded by

hasan118dutch
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
5 views

Java VS C or C++

The document discusses the performance of Java compared to C/C++. It notes that Java can be faster than C/C++ for some applications and discusses how the Java virtual machine and garbage collection contribute to performance. It also talks about issues with assumptions made by some Java libraries.

Uploaded by

hasan118dutch
Copyright
© © All Rights Reserved
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

Most C/C++ developers think Java is slow.

Java is usually faster than C/C++.

Take a look at Cassandra. 100% pure Java, one of the fastests databases, and it can
scale infinitely. Nothing in compares. Taking a snapshot of the database is almost
instantaneous.

HSQLDB, arguably the fastest database, also is 100% pure Java. You look at the code
and it makes you cry on how simple it is.

There are some exceptions though. Some code in Java looks like some C++ programmer
did it. The libraries in Java are too many to elaborate and some XML parsing
libraries I've met are ridiculous, the use to much memory, they even create classes
on the fly (meaning they are incredibly slow, use too many resources, you get
Permgen space errors, because they create new classes and the classes are stored in
a special place called Permgen in Java <= 1.6), so yes, working in Java usually
means selecting libraries carefully and monitoring your application to replace the
offending libraries as soon as you find out.

Java beats C/C++ because of the memory management. In Java, the new operator always
return in just what it takes to increment a pointer, which is blazing fast. In C/C+
+ you go into a special part of the program, you need synchronization, and then
there is an algorithm to find the right place and right amount of memory,
scavenging through a linked list of memory. It can take a while.

Garbage collection is not a problem if you use the parallel collector. Now all
computers have several cores, so if one of the cores is dedicated to garbage
collection it is not a problem.

The JVM bytecode gets compiled into machine code when it is being executed too
much. this compilation is almost instantaneous. And it beats C/C++ because it is
compiled once it has been executed so the compiler knows more than the C/C++
compiler will ever know. In the JVM platform this is known as the hotspot compiler.
This was actually copied from the Smalltalk environment where this was invented.

Java is not a difficult language, like C and C++ are. Any competent programmer can
learn Java in 6 months. The same programmer would need 3 years to learn C++ at the
same level.

The problem with Java are the set of libraries. They are too many. And the
information for using them is sparse. The documentation for some of them explain so
few things that makes it look that it is so simple, while in practice using them is
quite complex. One example is Hibernate. Hibernate has a concept of managed object,
so objects that can be persisted, once you persist them, Hibernate keep track of
them, and associate them with a Hibernate session. a hibernate session can be
thought as a database transaction. So if you performed an operation in a Hibernate
session, you can't mix an match objects in one session with another session.

This create a lot of problems. And this is explained where? Nowhere. So you realize
the problem, you need to create a document explaining the problem and then you need
to device a whole architectural design in order for developers to follow so that
this doesn't happen anymore.

Most libraries operate with he wrong set of assumptions. Hibernate operate on the
assumption that you will keep objects in RAM between Hibernate sessions (and then
complain if you reuse them). That's the wrong assumption. How could you store those
objects in RAM if the database is the object that persists those objects? Are they
supposed to fit in RAM? Is the database supposed to update the objects in RAM when
another process changes them in the database? Those are the wrong assumptions.
Keeping them is RAM is the worst assumption ever.

The same goes true for Vaadin. Vaadin assumes that all objects representing the
model stay up in RAM. If I need to refresh those objects from the database every
time I need to display them, it is kind of obvious the same will be true for screen
objects.

Isn't that obvious?

So yes, developing in Java usually means you need to figure out what the library
developers were thinking and correcting your code to handle things gracefully.

I would say 90% of the effort is finding the right libraries and correcting your
code to handling the library code correctly. That of course is documented nowhere
and when Java projects get late, they blame it on the language rather than on the
libraries, because for most people those libraries don't even exist, and for the
ones who have heard their name, they are so new... that they couldn't possibly be
wrong.

You might also like