Colin,
I would NOT recommend this site. It was last updated in '98. Many of
the optimizations listed were great for back then. They are terrible
for 2007 and will likely result in SLOWER execution, not faster.
For example, the claim is that a synchronized method call is 10 times
slower than one which is not synchronized. While true in '98, this has
changed considerably and is now patently false. The cost of
acquiring/releasing a lock in most modern production available VMs is
now measured in parts of a percent. It is rarely worth optimizing this
out as the constraint(s)/bottleneck(s) are very likely elsewhere.
Completely changing your architecture to attempt to avoid
synchronization is now bad for your code (if you have any intentions to
make it multi-thread capable).
Another claim is marking a method "final" in an attempt to promote it to
be inlined by the compiler. In '98, this could have a substantial
impact on performance. Now, it not only does not desirably impact
performance, the modern JVMs have sophisticated implementations around
inlining including inlining based on probability with exceptions
branched out of a default execution flow path (making the exceptions
slower, but the default path the fastest), it makes the class(es) less
flexibly to future adaptation.
If you are writing high performance Java code, it is worth your while to
find references that are no more than 4 years old. The JVMs have change
so much in the last 10 years, any assumptions from a recent as 4 years
ago are likely fallacious.
If you want to follow performance trends and very fixated execution
performance engineering for Java, I would recommend starting here:
http://www.javaperformancetuning.com/
And for a book:
http://www.amazon.com/exec/obidos/ASIN/0596003773/javaperforman-20
I have used both the site and the book for my own Java performance
tuning. Excellent stuff.
Jim
Colin Kern wrote:
On Nov 20, 2007 1:56 PM, Nick Apperson <[EMAIL PROTECTED]> wrote:
On Nov 20, 2007 12:48 PM, Stefan Nobis <[EMAIL PROTECTED]> wrote:
"Colin Kern" <[EMAIL PROTECTED]> writes:
I think the reason for Ruby being so much slower is because it is an
interpreted language rather than a compiled language.
It's not the main problem (interpreted languages are slower than those
compiled to native code, but than even Java and C# are interpreted and
don't have such big slowdowns).
Java and C# are both compiled at some point if the same loop is running
repeatedly. Java is usually compiled "just in time" which is to say as each
function is first run. I'm not sure how C# is executed, but I think it gets
compiled before execution.
I just found this looking around for things about Java's speed. Looks
like some useful ways to boost Java's performance.
http://www.cs.cmu.edu/~jch/java/speed.html
-Colin
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
