Java slow ?

[Lee Fesperman]

I don't think this is a particularly useful division of the question.
The things that mainly make Java performance different from C++
performance are mostly outside of the execution model these days. It's
simply fact that a good JIT compiler for Java is generally competitive
with statically compiled native code. The factors to consider in
performance are:

I agree, though JIT compilers can continue to get better (sometimes in larger leaps),
while C++ compilers will only improve in tiny increments.

1. Dynamic compiling; this is a factor in favor of Java, in that the JIT
can optimize for a specific set of hardware, whereas static compilers
can at best target a processor family. It's largely for this reason
that floating-point arithmetic in Java can be much faster than the
equivalent code in C++.

This is ultimately a big win for Java.

2. Garbage collection; while it can theoretically go either way, it
seems that in practice garbage collection in Java is a little slower
(but easier and safer) than manual dynamic memory management in C++.
The margin becomes smaller, though, as improvements are made to
algorithms... and it's very easy to write specific examples where a
garbage-collected heap is far faster.

It is possible for C++ to be better here. A well-written C++ program can be better, but
these are rare. The vast majority have serious problems with memory management, so this
really gives the advantage to Java.

3. Object model; C++ has the performance advantage in allowing the
programmer to use pseudo-objects explicitly on the stack. These objects
are a bit unorthodox with OO expectations (they don't have identity in
any meaningful sense, for one), but they do allow some programming tasks
to be solved without use of dynamic heap memory, and that can be a
performance win.

This advantage can be eliminated by an advanced JVM.

4. Threading; while threading is easier in Java than C++, it's also
profusive, in ways that can sometimes cause performance issues. This
makes some Java slower than some C++.
Agreed.

None of those problems are solved with a native compiler, although
advantage #1 for Java can be lost. Native compilers can also do wonders
for memory use and startup penalty. However, the chance at a small
margin of improvement in a static compiler over a JIT is not
particularly significant compared to the remainder of factors in Java's
performance.

Yes, native compilation is just not a viable option for Java, except in extremely rare
cases.

 

[David Eng]

Hi,

[this is not a message to start a flame war]

I often heard that Java is slow. Does someone is aware of any papers
describing this fact ? I'm not looking for comparisons between Java and
<name your favorite language here>. I'm looking for a paper describing what
could be the causes of the slowness of Java.

e.g.: object orientation, bytecode interpretation, ...

So, if anyone knows a good paper describing that fact, I would be more
grateful

Thanks in advance,
Henry

The papers claim the Java is as fast as C++ is fundamentally false.
The slowness of Java is not cause by the same language feature
comparing with C++. It is because of lacking of flexibility Java has.
I will give you two examples to explain it.

Java and C++ can create objects in the heap. If you compare this
feature between Java and C++, no doubt that the speed is about the
same. However, C++ can allow you to create object in stack. In this
case, object creation is fast than in the heap. Most papers don't do
this kind of comparison. But in real world, the lack of flexibility
makes Java slower.

The second example is array. If Java and C++ allocate an array using
index, the speed should be the same. However, C++ allows you using
pointer arithmetic. Instead of locating an element of array you must
start from the begin of the array every time, pointer arithmetic can
locate the element based on previous position. When the elements of
the array increase, the speed of allocating an array using index will
much slower that pointer arithmetic.

There are more these kinds of problems Java has. However, most
academic papers only compare with same language feature between Java
and C++. That's why they claim Java runs as fast as C or C++. That
is true. But in real world, people can implement functionality using
different techniques which C/C++ give to make software runs quickly.
This is why you heard Java is slow comparing with C or C++.

 

[Mark Thornton]

While Java bytecode, by nature, must be slower to run than natively-compiled
binaries coming from C++ source,

Most current JVM compile any methods which take a significant amount of
time to run. This is then native binary code just like that a C++
compiler might produce. The code quality is typically comparable to that
of Microsoft's C++ compiler, but less good than Intels latest compiler
(on x86).

I think my biggest problem is the CPU and
memory usage you see in any relatively large Java application. (NetBeans,

Most of the memory use of NetBeans occurs for reasons that have little
to do with the language used to implement it. Rather it is caused by the
large amounts of metadata maintained about your project, background
compilations etc.

Mark Thornton

 

[Mark Thornton]

I have one data point. Looking at
performance in windows task master
it takes approximately twice the time
to compile 50 java files using javac
compared to using jikes

Last time I compared javac and Jikes, Jikes failed to correctly compile
my source (problems relating to inheritance of inner classes). So on
that test it didn't score too well.

Mark Thornton

 

[Carl Howells]

Java and C++ can create objects in the heap. If you compare this
feature between Java and C++, no doubt that the speed is about the
same.

Completely wrong. Allocating objects on the heap in Java is FAST.
(It's the initialization of the object that takes time, not the
allocation.) The new operator in C++ has to do MUCH more work to
allocate an object than the new operator in Java, because of the way
modern garbage collection algorithms lay out the heap.

The second example is array. If Java and C++ allocate an array using
index, the speed should be the same. However, C++ allows you using
pointer arithmetic. Instead of locating an element of array you must
start from the begin of the array every time, pointer arithmetic can
locate the element based on previous position. When the elements of
the array increase, the speed of allocating an array using index will
much slower that pointer arithmetic.

Well, at least this isn't completely wrong. It's just mostly wrong.
It's actually fairly trivial for a compiler to optimize indexed array
lookups in a loop to pointer increments in that loop. I'm not actually
certain that this is done in any JVM, (it wasn't a few years ago), but
it certainly will be in the future.

Remember: In terms of optimization, lack of flexibility is a good
thing. When the language just doesn't let you screw up code the way C
and C++ do, the compiler can safely employ optimizations that just
aren't possible in C or C++.

Take a good compilers course sometime. You'll learn quite a bit.

 

[Mark Thornton]

The second example is array. If Java and C++ allocate an array using
index, the speed should be the same. However, C++ allows you using
pointer arithmetic. Instead of locating an element of array you must
start from the begin of the array every time, pointer arithmetic can
locate the element based on previous position. When the elements of
the array increase, the speed of allocating an array using index will
much slower that pointer arithmetic.

Absolute rubbish. Java array access can be slower due to the requirement
to check array bounds, but even this can often be optimised away when
the complier can prove the index will be within bounds. In addition
C/C++ pointer arithmetic carries the hazard of aliassing; the absence of
this type of aliassing can allow optimisations in Java which are not
safe in C/C++.

Mark Thornton

 

[Tony Morris]

Most such paper will be completely out of date and I doubt there is

any that can truly claim to adress all issues. This is because the reasons
for the "slowness" of Java have changed over the years as JVM and JIT
compiler technology improved. Each time major performance problem were
solved, new ones that had previously been minor got the focus of
attention. The result is that most discussions of Java's speed problems,
and how to solve or avoid them only adress those problems that were
"fashionable" at the time the article was written.

Nowadays, Java is *not* slow.

I couldn't agree more.

"I often heard that Java is slow."

What you have heard is incorrect, and often unfounded due to a number of
reasons, such as; ignorance to the reality or being outdated (as suggested).

So the simple answer is that the basis for your request is flawed, so your
request can never be fulfilled.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

While Java bytecode, by nature, must be slower to run than natively-compiled
binaries coming from C++ source

That is not no longer true. That is true only if you interpret byte
codes, but you have at least three other option besides that.
Interpreting is not even the default. You can also JIT, static
natively compile and hotspot.

see http://mindprod.com/jgloss/compiler.html

 

[Roedy Green]

Last time I compared javac and Jikes, Jikes failed to correctly compile
my source (problems relating to inheritance of inner classes). So on
that test it didn't score too well.

Jikes is version 1.2. What were you using?

 

[Roedy Green]

Java and C++ can create objects in the heap. If you compare this
feature between Java and C++, no doubt that the speed is about the
same. However, C++ can allow you to create object in stack.

Java compilers can do the same thing as an optimisation. You just
don't have to explicitly code it the way you do in C++. see
http://mindprod.com/jgloss/jet.html

 

[Roedy Green]

The second example is array. If Java and C++ allocate an array using
index, the speed should be the same. However, C++ allows you using
pointer arithmetic. Instead of locating an element of array you must
start from the begin of the array every time, pointer arithmetic can
locate the element based on previous position. When the elements of
the array increase, the speed of allocating an array using index will
much slower that pointer arithmetic.

It is one addition slower. In a Pentium class machine that addition
can be done for free using an index register. That is not exactly
"much slower"

 

[Roedy Green]

Remember: In terms of optimization, lack of flexibility is a good
thing. When the language just doesn't let you screw up code the way C
and C++ do, the compiler can safely employ optimizations that just
aren't possible in C or C++.

Pointers turn off nearly all optimisation because the compiler has
absolutely no idea what you are doing. References are much better
behaved and the compiler KNOWS you are not doing anything weird, and
so can optimise.

The OP is arguing on theoretical grounds without actually studying any
of the code generated or benchmarking.

 

[James Moughan]

Absolute rubbish. Java array access can be slower due to the requirement
to check array bounds, but even this can often be optimised away when
the complier can prove the index will be within bounds. In addition
C/C++ pointer arithmetic carries the hazard of aliassing; the absence of
this type of aliassing can allow optimisations in Java which are not
safe in C/C++.

Mark Thornton

I keep hearing that Java arrays are close to C++ arrays for speed; and
they keep running about one-third as fast. 'Fraid I don't have any
theoretical justification for that, I had to resort to going out and
timing it...

The real killer speed comparison would be java.util.ArrayList vs
std::vector, though. Java has nothing remotely comparable to
std::vector for primitive types.

Generally it's just not that important, though. Java is fast *enough*
for most things you want to do that don't require unlimited resources
in the first place. It's strange how people seem so much more
obsessed with speed in Java than in pretty much any other language.

Personally I'd prefer a reduction in memory usage to speed
optimisation, and a whole bunch of syntactic sugar to that.

 

[Michael Borgwardt]

I think my biggest problem is the CPU and
memory usage you see in any relatively large Java application. (NetBeans,
which I enjoy using, does take quite some time to load, and screen redraws

That's mainly because NetBeans encompasses a *firggin' huge* pile of
functionality. OpenOffice, which is similar in scope but written in C++,
takes nearly as long to load.

 

[Chris Uppal]

I actually don't think that's a reasonable assessment, but the reason is
rather complex.

I'm afraid I must disagree...

There are several algorithms for garbage collection. Algorithms that
primarily follow copying collection will cost on the order of live
objects

Ok with that, yes....

and algorithms that primarily follow mark/sweep or ref-counting
will cost on the order of dead objects.

Sorry, but although there is a clear sense in which ref-counting cost are
determined by the rate at which objects die, the same can't be said of
mark-sweep. The marking phase -- almost by definition -- does work
proportional to the number of live objects. If you really do have an explicit
sweep phase (I've never understood why anyone would want to, even in an
early/primitive/simple GC) then that does work proportional to the size of the
entire heap or, with a little optimisation, to the size of the portion of the
heap that was in use before the GC.

Because of statistical data
about object lifetimes, it turns out that it's generally best to choose
copying for younger generations and mark/sweep for older generations.
In fact (though my experience is limited) I've never seen a modern real-
world GC implementation that uses copying in the older dimensions.

Tempting to use ref-counting for the oldest generations. With modern
optimisations like not "counting" refs that are on the stack(s) and perhaps one
could do something analogous to card-marking to keep track of references into
the old space. The point is that writes into the oldspace are going to trip
over the write-barrier anyway, so why not do ref-counting then too ? I don't
know of any implementations that do that. But re-counting (or derived
techniques) do seem to be coming back into the limelight of GC research as
memories get bigger ("vaster", might be a better word. I can't, personally,
see much point in advanced techniques for normal sized applications -- even a
naive mark-and-no-sweep will in fact work perfectly well for most desktop sized
apps with object counts of a few million or less, and birth rates mostly
determined by user activity).

-- chris

 

[Andrew Thompson]

...(NetBeans,
which I enjoy using, does take quite some time to load, and screen redraws
can be slow, for example. I have a 2.0GHz Pentium IV and 256MB of RAM. I know
adding more memory will fix the problem, but dammit, why should I *have* to?!

I have 512Meg and *still* have trouble!

Though I usually *also* have around 10 IE
browser windows open, a Mozilla window (or two),
a couple of directories, StarOffice (with 6
or 7 documents open), local server running,
TextPad (with 9 to 15 docs open), OE and
40tudeDialog, oh.. and of course the jukebox
playing 128-320Kbps music's, ..but that
wouldn't take up much resources,
'cos it's in the start-up.. ;-)

 

[Manish Hatwalne]

It would be great if this thread can be archived, great source of
information.

- Manish

 

[Andrew Thompson]

It would be great if this thread can be archived, great source of
information.

Manish.. I cannot -quite- tell if you
are joking or not, so (shrugs)...
<http://google.com/groups?thl=0,8406...28203,840523127,840494540,840427632,840418275>

[ And if you are joking.. ROTFL! ;-) ]

 

[Jesper Nordenberg]

The real killer speed comparison would be java.util.ArrayList vs
std::vector, though. Java has nothing remotely comparable to
std::vector for primitive types.

That's not the speed of the JVM you're measuring, it's the speed of a
library. Collections for primitive types are not included in the JRE,
but can downloaded libraries like pcj.sourceforge.net and
trove4j.sourceforge.net.

/Jesper Nordenberg

 

[Steven J Sobol]

That's mainly because NetBeans encompasses a *firggin' huge* pile of
functionality. OpenOffice, which is similar in scope but written in C++,
takes nearly as long to load.

Ok, but a little application I'm writing that uses maybe six or eight
custom-written classes takes forever to load too. (somewhere between five
and ten seconds). It just doesn't swap once it's loaded, like NetBeans does.

I don't see any significant difference between C++ or Visual Basic and Java
where execution is concerned...

--
JustThe.net Internet & New Media Services, Apple Valley, CA PGP: 0xE3AE35ED
Steven J. Sobol, Geek In Charge / 888.480.4NET (4638) / (e-mail address removed)
Domain Names, $9.95/yr, 24x7 service: http://DomainNames.JustThe.net/
"someone once called me a sofa, but i didn't feel compelled to rush out and buy
slip covers." -adam brower * Hiroshima '45, Chernobyl '86, Windows 98/2000/2003