Java slow ?

[Henry]

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

 

[Michael Borgwardt]

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

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.

 

[Chris Uppal]

I'm looking for a paper describing
what could be the causes of the slowness of Java.

You won't find any.

What you will find are:

Java implementations that are /in fact/ slow -- these will either be toys or
designed for special purposes where speed is less important than something else
(memory footprint, perhaps). Real, general purpose, production JVMs are not
slow.

Papers on optimisations used in JVMs (and VMs for other languages) that discuss
and evaluate various implementation techniques. There are papers on both the
Sun and IBM websites about the optimisations in their respective JVMs. You
could also look into past OOPSLA conference proceedings (don't limit yourself
to papers that mention Java in the title). And any other source of academic
technical publications that you can think of. Citeseer will help too. There a
/mass/ of material out there, far too much for me to try to think of specific
links.

-- chris

 

[Wee Jin Goh]

Hi,

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

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

No, I'm not aware of any papers describing why Java is slow, because
that isn't really a fact. Java isn't slow.

Here's a page that pools together various documents from around the web
discussing Java's performance.
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Hope that helps.
Wee-Jin

 

[Steve W. Jackson]

:Henry wrote:
:
:> 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
:
: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.

Furthermore, the OP is looking for a paper that presents arguments that
explain the truth of his presupposed "fact" that Java is slow. I've
spent the past 3+ years of my professional life developing and
maintaining a Swing application that does simulation and modeling, and
Java is definitely not slow.

= Steve =

 

[Trent]

Yes, Java is slower then, say, a compiled C++ program. But that is
not comparing apples to apples.

YOU can compile JAVA into an EXE (using JET), and get about the
same results, and actually compare apples to apples.

I can write something in JAVA, usually, about 5 times faster then
my brother can in C++, and many times faster using when a GUI is
needed.

The Java Code is many times more portable to other plateforms.

The Java Code usually has no memory leaks, and somewhat maintainable.
I HAVE NEVER SEEN C++ MAINTAINABLE CODE as a project lead. The coders
write it go cryptic and don't document.

have a hoot.

 

[Chris Smith]

Yes, Java is slower then, say, a compiled C++ program. But that is
not comparing apples to apples.

YOU can compile JAVA into an EXE (using JET), and get about the
same results, and actually compare apples to apples.

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:

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++.

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.

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.

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++.

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.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[ak]

I HAVE NEVER SEEN C++ MAINTAINABLE CODE as a project lead. The coders

write it go cryptic and don't document.

may be they just trying to ensure that they doesn't lose their jobs (because
nobody else can understand their code ;-)

 

[Dimitri Maziuk]

Henry sez:

Hi,

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

Hehehehe. That's like posting to a linux advocacy ng:
Linux sucks worse than windows [not a flamebait]

I often heard that Java is slow. Does someone is aware of any papers
describing this fact ?

I don't think you'll find any. With all the hype surrounding the
language it would be politically incorrect to write a paper like
that.

Anyway, it's not that Java is slow, it's that it doesn't scale. I.e.
as the size of input data grows, time it takes to run the program
grows also. "Doesn't scale" means it doesn't grow linearly. Of course,
proving that the slowdown is caused by the language and not by poor
choice of algorithms/crappy implementation by the programmer is an
excercise in itself... so good luck finding anything.

Dima

 

[Mark Thornton]

Henry sez:

Hi,

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

Hehehehe. That's like posting to a linux advocacy ng:
Linux sucks worse than windows [not a flamebait]

I often heard that Java is slow. Does someone is aware of any papers
describing this fact ?

I don't think you'll find any. With all the hype surrounding the
language it would be politically incorrect to write a paper like
that.

Anyway, it's not that Java is slow, it's that it doesn't scale. I.e.
as the size of input data grows, time it takes to run the program
grows also. "Doesn't scale" means it doesn't grow linearly.

That is true of all languages on all real hardware. Beyond a certain
point the problem just won't run at all! Before that, on machines with
virtual memory your task slows down as memory usage exceeds the
available real memory. There is nothing about Java (the language) which
makes it any better or worse than other languages in this respect. Some
Java implementations may be worse for some types of task relative to
some other choice of language (and some may be better).

Mark Thornton

 

[Chris Smith]

Anyway, it's not that Java is slow, it's that it doesn't scale. I.e.
as the size of input data grows, time it takes to run the program
grows also. "Doesn't scale" means it doesn't grow linearly. Of course,
proving that the slowdown is caused by the language and not by poor
choice of algorithms/crappy implementation by the programmer is an
excercise in itself... so good luck finding anything.

Interestingly enough, you've just stumbled across one of the few
statements that can be verified to be false. After all, while "slow"
and "fast" depend on a lot perception issues and the task at hand, the
claim that Java performance grows non-linearly with problem size is
different; it's easy to see that such a claim is false.

Java's computation model is the same as any other language, and the fact
that code will be running for a while doesn't make it any slower to
execute a given portion of it. JIT work is similarly proportional to
the amount of code to compile, and garbage collection is linear to the
number of objects to be (collected/preserved, depending on algorithms in
use). Hence, your statement is not true for execution speed. Even
more, Java environments typically scale better with multiple processors
than any common non-Java code. Furthermore, Java most certainly doesn't
use any more than a constant multiple of heap space versus the size of
data allocated. So, that can't be true for memory either.

It's possible that you meant to say something different; that for a
constant amount of memory and an increasing problem size, Java will
exhibit poor behavior faster. That is likely to be true, but you can be
certain that if you increased the available memory commensurately with
the increase is problem size, you would run into no problems... and
thus, the space complexity of code is not changed by its being written
in Java and your scalability concerns are misplaced.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Wee Jin Goh]

Yes, Java is slower then, say, a compiled C++ program. But that is
not comparing apples to apples.

YOU can compile JAVA into an EXE (using JET), and get about the
same results, and actually compare apples to apples.

Have you tried using JET with numeric code? Have you looked at the
benchmarks provided by Excelsior (the people who made JET)?

Then you'll see that JET doesn't bring any real performance advantage of
the standard server VM. Those benchmarks on Excelsior's page only deal
with the client VM, which is something you shouldn't be using if
performance is critical.

To automatically assume that a language running in a VM is going to be
slower is wrong. Java does compile byte code into native code, so the
end result is the same. Obviously, this then makes it a comparison of
the implementation of those languages, and not the languages per se. C++
compilers produce executables that run at different speeds. Likewise,
different Java VMs have different performance.

The point is, Java is not slower than C++. Look at the benchmarks on
that page. You'll see that there are cases where Java is faster than GCC
and is as fast as MSVC.NET.

Regards,
Wee-Jin

 

[Chris Uppal]

garbage collection is linear to the
number of objects to be (collected/preserved, depending on algorithms in
use).

Though it's worth noting that most current JMVs /do/ use GC algorithms where GC
time is proportional to the number of live objects. And so execution time
/can/ grow linearly with the size of live memory, which could fairly be
described as "doesn't scale".

Subject, of course, to the important observation that all sophisticated GC
algorithms contain optimisations that nearly always obviate this problem.
Still, they can't eliminate it in all cases, and they can't eliminate it
without help from the programmer in other cases, so it's one more thing for
people with Very Big datasets to keep in mind.

-- chris

 

[Chris Uppal]

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++.

My own impression is the opposite. The difference being (more than) made up
by:

3. Object model; C++ has the performance advantage in allowing the
programmer to use pseudo-objects explicitly on the stack.

I have to admit that its a couple of years since I last did much C++, so maybe
the allocators have moved on. (And it'll be system-dependent anyway...)

-- chirs

 

[Henry]

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

Thanks to all the people who replied to my post. I read all your answers
and now I understand my misunderstanding.

Thanks again.
Henry

 

[Chris Smith]

Though it's worth noting that most current JMVs /do/ use GC algorithms where GC
time is proportional to the number of live objects. And so execution time
/can/ grow linearly with the size of live memory, which could fairly be
described as "doesn't scale".

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

There are several algorithms for garbage collection. Algorithms that
primarily follow copying collection will cost on the order of live
objects, and algorithms that primarily follow mark/sweep or ref-counting
will cost on the order of dead objects. 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.

Every object is born once and dies once, and creating it requires non-GC
work. At most, the object will require the work to preserve itself as a
live object a finite number of times (equal to the number of times it is
copied, which is generally some multiple of the number of copy-collected
generations), plus the work to destroy it from the oldest generation.
That's a worst-case, and it is bounded to a constant multiple of the
non-GC time that was used to create the object. So we get linear time
execution with respect to the number of low-level instructions executed,
even taking GC into account.

Of course, the way to avoid this is to postulate a 100% copying
collector, which does indeed cause unbounded theoretical-worst-case
execution time. However, this would be a rather unusual implementation
in my experience. I've seen 100% mark/sweep, and I've seen 100% ref-
counting, but I've never seen 100% copying. It's always copy-then-...

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Mark Thornton]

Chris Smith wrote:




Though it's worth noting that most current JMVs /do/ use GC algorithms where GC
time is proportional to the number of live objects. And so execution time
/can/ grow linearly with the size of live memory, which could fairly be
described as "doesn't scale".

The allocators usually used with C/C++ don't execute in constant time
either. While you can override the default allocator in C/C++ there is a
significant maintenance penalty if you do that.

Mark Thornton

 

[Steven J Sobol]

1. Dynamic compiling; this is a factor in favor of Java, in that the JIT
2. Garbage collection; while it can theoretically go either way, it
3. Object model; C++ has the performance advantage in allowing the
4. Threading; while threading is easier in Java than C++, it's also

While Java bytecode, by nature, must be slower to run than natively-compiled
binaries coming from C++ source, 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
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?!

--
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

 

[Steven J Sobol]

may be they just trying to ensure that they doesn't lose their jobs (because
nobody else can understand their code ;-)

Yup. You *can* create maintainable C++ code. It might take more work than
other languages would require, but you can do it.

--
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

 

[Liz]

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