File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Performance and the fly likes Its not Java, its you (an opinion) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Its not Java, its you (an opinion)" Watch "Its not Java, its you (an opinion)" New topic
Author

Its not Java, its you (an opinion)

Alok Pota
Ranch Hand

Joined: Mar 07, 2001
Posts: 185
I don't think Java is slow. I think Java makes it easy to write good OOP code. Good OOP code is not necessarily fast performing code.
A lot is expected from a Java programmer. A Java programmer is supposed abstract, wrap, write factories, seperate model from the view (to name a few). I am sure if we imposed the same requirements on a PHP developer. The PHP application would be slow. Why is it ok for a ASP/PHP developer to mix layers of abstraction and write one ugly fast performing mess but the same done done by a Java programmer is scoffed at.
Could it be that a Java programmer is
held at a higher standard?
Take a look at some of the exception stack traces
generated these days. We have 100 method calls before something actually gets done!. Are we over engineering and then blaming Java?
-Just an opinion
Lu Battist
Ranch Hand

Joined: Feb 17, 2003
Posts: 104
I agree with you. I've seen many over engineered solutions as well. Maybe engineered is a bad word because it doesn't look engineered - a method call trace to get something done looks more like someone surfing the web. I also think Java's performance can be quite good if programmed properly. Developers have to remember method calls and object creation have overhead that should be minimized *not* maximized. The KISS (Keep it simple, stupid) priniciple should be emphasized more. There nothing worse than an over zealous pattern happy developer gone mad.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I strongly disagree with the notion that the number of method calls typically is responsible for performance problems and deep stack traces are somehow a sign of over-engineering.
First, with the speed of modern JVMs it is a reasonable approach to pretend that method calls don't take time. (For the most important ones that might even be true, as the Hotspot Engine might decide to inline them.)
Second, big classes with big methods aren't simple, and they aren't fast. And what's even worse, they are complicated to performance-tune. They almost invariably contain lots of duplicated logic and therefore significantly reduce the effectiveness of optimizations - wether done by the programmer, the compiler or the runtime system.
You are right, though, that you shouldn't blame Java first for bad performance of your system. Instead, apply a profiler to find the bottlenecks - and hope that the system is well factored and decoupled, so that it's easy to identify and improve the critical parts.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Chris Stewart
Ranch Hand

Joined: Sep 14, 2002
Posts: 184
I agree that some of the lack of speed is dependent on the programmer, not just the language. But, since Java is an interpreted language regardless of how well it is written, it will still be slower than a language such as ASM, C, or C++.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Chris Stewart:
I agree that some of the lack of speed is dependent on the programmer, not just the language. But, since Java is an interpreted language regardless of how well it is written, it will still be slower than a language such as ASM, C, or C++.

That's simply wrong. Java is compiled to native code at runtime by the Hotspot Engine. By analyzing the dynamic runtime behaviour, it is even able to do some optimizations which can't be applied statically at runtime.
Where Java is slower than C++, for example, it's mainly due to enhanced safety - boundary checking at array access etc.
Jeff Carlson
Greenhorn

Joined: Mar 31, 2003
Posts: 4
Originally posted by Chris Stewart:
I agree that some of the lack of speed is dependent on the programmer, not just the language. But, since Java is an interpreted language regardless of how well it is written, it will still be slower than a language such as ASM, C, or C++.

Well, not really so much. If Java were run in interpreted mode (no form of JIT) then sure, you are absolutely right.
I have been working on a clustering algorithm recently. The optimized Java version is about 41% slower than the heavily optimized C version when you run with the standard Sun JIT (1.4.1_02 is a teeny bit faster when you run with -server). However, running with the new JRocket JIT, the same code (no recompiles or anything - just change the classpath to get the JRocket kit before the sun kit) and it is 28% _faster_ than the optimized C code.
In theory you are correct that Java by it's nature is slower, but in practice, with a good JIT (my best results were the IBM Linux JIT and the JRockit Windows JIT) and the right problem (even a heavy computation problem like this one) and you will kick the staticly compiled code (even the heavily optimized staticly compiled code).
Cheers.
P.S. (edit; don't you feel glad that this thread inspired me to join JR and offer my first post here? )
[ March 31, 2003: Message edited by: Jeffrey Carlson ]
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
P.S. (edit; don't you feel glad that this thread inspired me to join JR and offer my first post here? )
Yes -- Welcome!
SJ Adnams
Ranch Hand

Joined: Sep 28, 2001
Posts: 925
Jeffrey,
That is a fantastic performance gain. I was thinking of rewriting LSSOL in java. I rewrote it in C++ about 5 years ago (it's STILL only available in F77 commercially), the performance gain for my specific application was around 10fold when written in C++ (primarily due to memory footprint), I might give it a go in java now
Simon
The Moose
Bartender

Joined: Apr 01, 2003
Posts: 73
I think that the main problem with c++ is the lack of a Moose.


Finally! Animal rights in action!
Francis Siu
Ranch Hand

Joined: Jan 04, 2003
Posts: 867
Yes
I agree with the statement from The Moose
Nick name approved?
I think that the main problem with c++ is the lack of a Moose



Francis Siu
SCJP, MCDBA
 
jQuery in Action, 2nd edition
 
subject: Its not Java, its you (an opinion)
 
Similar Threads
Java V's PHP for Building Websites
New to Java Web Application
Strengths and Weaknesses of various programming languages
OOP considered harmful (was: C. Date on UML book)
SWT versus Swing/awt