Java Performance Tuning, 2nd Ed.

cpfeifer writes "Performance has been the albatross around Java's neck for a long time. It's a popular subject when developers get together "Don't use Vector, use ArrayList, it's more efficient." "Don't concatenate Strings, use a StringBuffer, it's more efficient." It's a chance for the experienced developers to sit around the design campfire and tell ghost stories of previous projects where they implemented their own basic data structures {String, Linked List...} that was anywhere from 10-50% faster than the JDK implementation (and in the grand oral tradition of tall tales, it gets a little more efficient every time they tell it)." Want to kill the albatross? Read on for the rest of cpfeifer's review of O'Reilly's Java Performance Tuning, now in its 2nd edition. Java Performance Tuning, 2nd Edition author Jack Shirazi pages 570 publisher O'Reilly and Associates rating 9/10 reviewer cpfeifer ISBN 096003773 summary It's the most up to date publication dealing specifically with performance of Java applications, and is a one of a kind resource.

Every developer has written a microbenchmark (a bit of code that does something 100-1000 times in a tight loop and measure the time it takes for the supposed "expensive operation") to try and prove an argument about which way is "more efficient" based on the execution time. The problem, is when running in a dynamic, managed environment like the 1.4.x JVM, there are more factors that you don't control than ones that you do, and it can be difficult to say whether one piece of code will be "more efficient" than another without testing with actual usage patterns. The second edition of Review of Java Performance Tuning provides substantial benchmarks (not just simple microbenchmarks) with thorough coverage of the JDK including loops, exceptions, strings, threading, and even underlying JVM improvements in the 1.4 VM. This book is one of a kind in its scope and completeness.

The Gory Details
The best part of this book is that it not only tells you how fast various standard Java operations are (sorting strings, dealing with exceptions, etc.), but he has kept all of the timing information from the previous edition of the book. This shows you how the VMs performance has changed from version 1.1.8 up to 1.4.0, and it's very clear that things are getting better. The author also breaks out the timing information for 3 different flavors of the 1.4.0 JVM: mixed interpreted/compiled mode (standard), server (with Hotspot), and interpreted mode only (no run time optimization applied).

Part 1 : Lies, Damn Lies and Statistics
The book starts off with three chapters of sage advice about the tools and process of profiling/tuning. Before you spend any time profiling, you have to have a process and a goal. Without setting goals, the tuning process will never end and it will likely never be successful.

The author outlines a general strategy that will give you a great starting point for your tuning task forces. Chapter 2 presents the profiling facilities that are available in the Java VM and how to interpret the results, while chapter 3 covers VM optimizations (different garbage collectors, memory allocation options) and compiler optimizations.

Part 2 : The Basics
Chapters 4-9 cover the nuts and bolts, code-level optimizations that you can implement. Chapter 4 discusses various object allocation tweaks including: lazy initialization, canonicalizing objects, and how to use the different types of references (Phantom, Soft, and Weak) to implement priority object pooling. Chapter 5 tells you more about handling Strings in Java that you ever wanted to know. Converting numbers (floats, decimals, etc) to Strings efficiently, string matching -- it's all here in gory detail with timings and sample code.

This chapter also shows the author's depth and maturity; when presenting his algorithm to convert integers to Strings, he notes that while his implementation previously beat the pants off of Sun's implementation, in 1.3.1/1.4.0 Sun implemented a change that now beats his code. He analyzes the new implementation, discusses why it's faster without losing face. That is just one of many gems in this updated edition of the book. Chapter 6 covers the cost of throwing and catching exceptions, passing parameters to methods and accessing variables of different scopes (instance vs. local) and different types (scalar vs. array). Chapter 7 covers loop optimization with a java bent. The author offers proof that an exception terminated loop, while bad programming style, can offer better performance than more accepted practices.

Chapter 8 covers IO, focusing in on using the proper flavor of java.io class (stream vs. reader, buffered vs. unbuffered) to achieve the best performance for a given situation. The author also covers performance issues with object serialization (used under the hood in most Java distributed computing mechanisms) in detail and wraps up the chapter with a 12 page discussion of how best to use the "new IO" package (java.nio) that was introduced with Java 1.4. Sadly, the author doesn't offer a detailed timing comparison of the 1.4 NIO API to the existing IO API. Chapter 9 covers Java's native sorting implementations and how to extend their framework for your specific application.

PART 3 : Threads, Distributed Computing and Other Topics
Chapters 10-14 covers a grab bag of topics, including threading, proper Collections use, distributed computing paradigms, and an optimization primer that covers full life cycle approaches to optimization. Chapter 10 does a great job of presenting threading, common threading pitfalls (deadlocks, race conditions), and how to solve them for optimal performance (e.g. proper scope of locks, etc).

Chapter 11 provides a wonderful discussion about one of the most powerful parts of the JDK, the Collections API. It includes detailed timings of using ArrayList vs. LinkedList when traversing and building collections. To close the chapter, the author discusses different object caching implementations and their individual performance results.

Chapter 12 gives some general optimization principles (with code samples) for speeding up distributed computing including techniques to minimize the amount of data transferred along with some more practical advice for designing web services and using JDBC.

Chapter 13 deals specifically with designing/architecting applications for performance. It discusses how performance should be addressed in each phase of the development cycle (analysis, design, development, deployment), and offers tips a checklist for your performance initiatives. The puzzling thing about this chapter is why it is presented at the end of the book instead of towards the front, with all of the other process-related material. It makes much more sense to put this material together up front.

Chapter 14 covers various hardware and network aspects that can impact application performance including: network topology, DNS lookups, and machine specs (CPU speed, RAM, disk).

PART 4 : J2EE Performance
Chapters 15-18 deal with performance specifically with the J2EE APIs: EJBs, JDBC, Servlets and JSPs. These chapters are essentially tips or suggested patterns (use coarse-grained EJBs, apply the Value Object pattern, etc) instead of very low-level performance tips and metrics provided in earlier chapters. You could say that the author is getting lazy, but the truth is that due to huge number of combinations of appserver/database vendor combinations, it would be very difficult to establish a meaningful performance baseline without a large testbed.

Chapter 15 is a reiteration of Chapter 1, Tuning Strategy, re-tooled with a J2EE focus. The author reiterates that a good testing strategy determines what to measure, how to measure it, and what the expectations are. From here, the author presents possible solutions including load balancing. This chapter also contains about 1.5 pages about tuning JMS, which seems to have been added to be J2EE 1.3 acronym compliant.

Chapter 16 provides excellent information about JDBC performance strategies. The author presents a proxy implementation to capture accurate profiling data and minimize changes to your code once the profiling effort is over. The author also covers data caching, batch processing and how the different transaction levels can affect JDBC performance.

Chapter 17 covers JSPs and servlets, with very little earth shattering information. The author presents tips such as consider GZipping the content before returning it to the client, and minimize custom tags. This chapter is easily the weakest section of the book: Admittedly, it's difficult to optimize JSPs since much of the actual running code is produced by the interpreter/compiler, but this chapter either needs to be beefed up or dropped from future editions.

Finally, chapter 18 provides a design/architecture-time approach towards EJB performance. The author presents standard EJB patterns that lend themselves towards squeezing greater performance out of the often maligned EJB. The patterns include: data access object, page iterator, service locator, message facade, and others. Again, there's nothing earth shattering in this chapter. Chapter 19 is list of resources with links to articles, books and profiling/optimizing projects and products.

What's Bad?

Since the book has been published, the 1.4.1 VM has been released with the much anticipated concurrent garbage collector. The author mentions that he received an early version of 1.4.1 from Sun to test with. However, the text doesn't state that he used the concurrent garbage collector, so the performance of this new feature isn't indicated by this text.

The J2EE performance chapters aren't as strong as the J2SE chapters. After seeing the statistics and extensive code samples of the J2SE sections, I expected a similar treatment for J2EE. Many of the J2SE performance practices still apply for J2EE (serialization most notably, since that his how EJB, JMS, and RMI ship method parameters/results across the wire), but it would be useful to fortify these chapters with actual performance metrics.

So What's In It For Me?

This book is indispensable for the architect drafting the performance requirements/testing process, and contains sage advice for the programmer as well. It's the most up to date publication dealing specifically with performance of Java applications, and is a one-of-a-kind resource.

You can purchase Java Performance Tuning, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Web pages

[Mattygfunk1]

For applications and easy of development Java is sensational, but for everybodys sake PLEASE DON'T USE JAVA ON WEB PAGES WHEN IT ISN'T NECESSARY. As you might pick up on - I hate it, and most of your users do too.

Networking and secure transactions asside, I have a major problem with things like scrolling text java applets. The problem is I see it too much.

/pet-hate rant. grrrrr.

__
cheap web site hosting with coins per month.

Re:Web pages

[catch23]

Why would the users care whether you use a J2EE or PHP4 backend? You must be thinking of Java applets which very few few people actually use for any "web page development". And the chapters 15-18 that talk about J2EE, what's wrong with using J2EE for the generation of webpages and content?

Re:Web pages

[juhaz]

He said on web pages. Obviously applets. And he's right, they suck, even a fast and small applet feels very slow because of time it takes to start jvm.

Backend isn't on web pages, or in web pages, it's generating those web pages.

Re:Web pages

[msuzio]

People are still using applets? Huh. Didn't know that. Applets are *so* 1996, don't you think? ;-)

Now, on the *server* side, well, Java just plain rocks. Servlets+JSP (when done right, not done moronically and with overuse of EJBs when they aren't needed) is very nice indeed.

Re:Web pages

[Malc]

You haven't been to http://games.yahoo.com/. It's all Java applets, and it works quite well.

Re:Web pages

[angel'o'sphere]

As you might pick up on - I hate it, and most of your users do too.

How will a user ever notice that you use Java on the server?

And why should he hate it if he notices? Would you suggest ASP instead?

angel'o'sphere

Re:Web pages

[KinkyClown]

Users may not care, as long as it does the job. A manager however must see / hear a few buzzwords or the product is automatically crap and uninteresting.

Isn't this the compiler's job?

[chrisseaton]

If all these performance hacks are documented, why doesn't the compiler implement them?

I've often found that will bytecode languages (Java, C#...) the bytecode instructions are made for the language so that the compiler can just throw them out easy peasy, but they seem to overlook the sort of optimizations that C compilers, for example, work hard to implement.

Re:Isn't this the compiler's job?

[p3d0]

Do you mean the Java compiler or the JIT compiler? If you mean the JIT compiler, keep in mind that JIT compilation occurs at runtime, so this kind of analysis would be prohibitively expensive.

In either case, I think they analysis you're asking for is the kind that's easy for a human to do, but harder for an algorithm to do automatically. I don't know what's involved, and it could probably be done, but to prove that these transformations are safe is no mean feat.

Re:Isn't this the compiler's job?

[chrisseaton]

Think about the string object problem - people have to use stringbuffer because strings are immutable.

When a program thrashes strings around, why doesn't the compiler detect that, and switch to a string buffer object to perform those operations, and then convert the final result back to a string?

Re:Isn't this the compiler's job?

[cmburns69]

With non-bytecode langauges, the compiler can optimize to the environment. It can re-order code based on the fastest execution time for the platform the code is compiled for.

Java (and other bytecode languages) were desinged to run well not just on a single platform, but on a variety of platforms. So as a trade-off, you lose environment-specific optimizations at compile time.

JIT JRE/compilers can work to prevent this. They can further optimize the bytecodes at execution time because they are platform specific.

An online Starcraft RPG? Only at
In soviet Russia, all your us are belong to base!

Re:Isn't this the compiler's job?

[jd10131]

Having a compiler swap objects out from under you would be

1. Tricky to implement properly
2. Rude

However, emitting a warning when the compiler thinks you could do a better job with a StringBuffer might be nice.

Re:Isn't this the compiler's job?

[dubious9]

actually, IIRC, that's what the compiler already does for inline concatenation i.e. System.out.println(thisstring+thatString);

Re:Isn't this the compiler's job?

[chrisseaton]

"Having a compiler swap objects out from under you would be ... rude"

I don't mean it to swap the object out, just use a temporary object for the operation.

When you say

string foo = "Hello, ";
foo += "World!";

You just want foo to hold the two strings concatenated, you don't care how the compiler did it. The compiler could create a temp stringbuffer object there for that operation, converting back to string and assigning to foo.

I don't see how that's rude, because the programmer wouldn't even know that it's happening, just like a C programmer doesn't know that the compiler will pad his structures so they fit nicely on a word boundary to increase performance.

Re:Isn't this the compiler's job?

[briaydemir]

If all these performance hacks are documented, why doesn't the compiler implement them?

The most common reason is that most performance hacks and optimizations are not decidable, and you want a compiler to implement only decidable algorithms becuase those are the ones that enable a compiler to be deterministic. It is usually much easier for a person, i.e., human, to determine what can be done, than it is for a machine to determine that exact same thing.

Consider the following piece of code.

boolean f(int[] a, int[] b)
{
int x = a[0];
b[0] = a[0] + 2;
int y = a[0];
return (x == y);
}

Does f always return true? Only if we can prove that a and b never point to the same array. A person maybe able to do this, but a machine would have great difficulty (assuming the machine could even do it).

So to sumarize, compiler's don't implement many optimization hacks becuase then they might not be deterministic, and that is a bad thing.

Re:Isn't this the compiler's job?

[gmarceau]

For most of theses transformations to be correct, the compiler has to prove there is only one pointer to the object -- in the whole program. Whole-program analyses are expensive, and so are point-to analysis. And there is just not that kind of time to spare in a JIT, where every second spent analysing the program is time spent not executing it.

The optimization the book proposes are all hit-or-miss adventures. Even for a programmer with intimate knowledge of the code, it is sometime difficult to predict if a change will help or imper performance. The compiler has even less chance to do so correctly -- and nobody like a compiler which slows down their code trying to optimize it.

Re:Isn't this the compiler's job?

[ruriruri]

Actually, most java compilers do exactly what you suggest. However, consider:

String foo = "Ripple in still water\n";
foo += "When there is no pebble tossed\n";
foo += "Or wind to blow.";

In this case, the compiler does the following steps:

1. Create new string "foo" with the initial value (this may already exist).
2. Turn foo into a StringBuffer and append "When ..."
3. Turn foo back into a String.
4. Turn foo into a StringBuffer and append "Or..."
5. Turn foo back into a String.

So you can see this is not optimal. A human could easily rewrite the code as:

StringBuffer foo = new StringBuffer( "Ripple in still water\n" );
foo.append( "When there is no pebble tossed\n" );
foo.append( "Or wind to blow" );
String bar = foo.toString();

Here, we've saved one StringBuffer creation and one StringBuffer.toString() operation. Hooray us! But I do not believe any java compiler will make this level of optimization. Perhaps they are smarter now.

Re:Isn't this the compiler's job?

[steve_l]

If you can assert statements (a!=b) at the start of the code, and the compiler uses these assertions then it can act on them. but nobody does, no compiler supports it, etc, etc. Visual C++ does support this trick, but I have never encountered its use in a real project.

I'd be happy with cache prefetch hints in both Java and C#, and portable hinting in C++ (you can do it with ugly macros)

Re:Isn't this the compiler's job?

[abiogenesis]

Actually it does. When you concatenate two strings, the compiler (at least recent versions of Sun's javac) automatically changes the code so that it uses StringBuffers.

See http://c2.com/cgi/wiki?StringBuffer

Re:Isn't this the compiler's job?

[Anonym0us Cow Herd]

If someone were building a compiler that contemplated making such optimizations, wouldn't it be better to have an option to output optimization hints to the programmer? If I use a certian switch, the compiler emits another output file of notes about the source code, and what optimizations it suggests might be in order.

Naturally, the programmer might see that since both array parameters a and b point to the same array, that this is not really a possible optimization. This realization by the programmer is equivalent to the programmer realizing to insert an assert( a != b );

Why not move the optimizations into the source code directly. This makes the optimization transparent. Furthermore, all optimizations were then supervised by the programmer, not automatically hacked in by the compiler, which could fail if the same array were passed in for both parameters a and b.

Re:Isn't this the compiler's job?

[mesterha]

The most common reason is that most performance hacks and optimizations are not decidable, and you want a compiler to implement only decidable algorithms because those are the ones that enable a compiler to be deterministic. It is usually much easier for a person, i.e., human, to determine what can be done, than it is for a machine to determine that exact same thing.

Algorithms are deterministic so there is no way the compiler is going to be nondeterministic. And I doubt that undecidable problems have much to do with practical optimization. The efficiency of the technique is the issue. Undecidability has to do with infinite sets of problems. If an optimization was so great, I'm sure people would be happy with a solution that only covered programs of a certain size. The problem is that the optimization is way too expensive.

Does f always return true? Only if we can prove that a and b never point to the same array. A person maybe able to do this, but a machine would have great difficulty (assuming the machine could even do it).

If a human can prove it so can a machine. What advantage to you think humans have. The intuition behind your idea is that the programmer himself should be able to realize if f always returns true since he wrote the code. However the programmers task is much easier than the compilers. The programmer knows how he wants the code to behave. The compiler only knows how the code behaves. Lots of human optimizations or missed optimizations turn out to be bugs.

Definite purchase

[Timesprout]

I have drastically cut back on my tech book purchases in recent times but this book will definitely be on my shopping list. The First edition offered many insights into not only getting the best performance from Java but also solid guidelines for when and where to apply optimisations.
As a side note I would disagree about performance being an albatross for Java. Well written Java code can be very high performant just as poorly written code in ANY language can perform slowly. Many of the performance issues associated with Java are inexperienced developers using inappropriate methods and objects.

New Title

[borg05]

Java Performance Tuning: A course in C programing

Re:New Title

[Anonymous Coward]

Writing secure server applications in C: A course in Java programming

Writing complex enterprise systems in C: A course in Java programming

Re:New Title

[Anonymous Coward]

Writing secure server applications that take less than several minutes to respond: A course in C++ programming

Writing complex enterprise systems that don't get cancelled, because they don't perform and are written by former Taxi drivers turned Java programmers: A course in C++ programming

Re:New Title

[borg05]

I wouldn't mind Java network programing . . .if it had selects. Until then, C all the way.

Is this a review or a synopsis?

[rfischer]

there is a difference, you know.

Correct ISBN is 0596003773

[zipwow]

The bn.com link is broken for me, here's the correct ISBN:

0596003773

Re:Correct ISBN is 0596003773

[gid]

for the lazy

Re:Correct ISBN is 0596003773

[MojoRilla]

Or buy it from Amazon here and save $4.49.

Java Strings are the main problem

[Anonymous Coward]

Each String is around 64 bytes of memory minimum. What a stupid decision to make such a fundamental data type so heavy weight.

Re:Java Strings are the main problem

[sohp]

... because no one will ever need more than 64 bytes.

Re:Java Strings are the main problem

[tijsvd]

Yes, it can be much more efficient: let's just take some memory, put the string into it, and end with a 0. That's safe enough, right? Right? :-)

Java performance better in the Sun IDE?

[192939495969798999]

I have noticed my JAVA programs run considerably faster under the Sun Forte/One IDE. Once the JAVA app is on its own (especially through a browser), it slows considerably. Does anyone else have experience with this phenomenon?

Re:Java performance better in the Sun IDE?

[dubious9]

I know with Eclipse, that it keeps an instance of the VM running so that it doesn't have to start every time you want to run or debug the program. This would only affect start up times though.

Re:Java performance better in the Sun IDE?

[Jord]

If you are running on a windows platform chances are your VM in your browser it the MS VM. Try making sure that your IDE and everything else on your system are using the same VM.

I am guessing that you are working on an applet and not an application since you mentioned running it in a browser. If that is the case then the appletviewer is going to run slower (personal experience).

Re:Java performance better in the Sun IDE?

[los furtive]

Your IDE has its own Java VM running, and it could be different from the one you have installed. Most, if not all IDEs will let you choose which VM to use (for example I use 1.3.1_07 for work projects while using 1.4.1_02 for my own stuff, both from the same IDE).

Process

[spakka]

The book starts off with three chapters of sage advice about the tools and process of profiling/tuning. Before you spend any time profiling, you have to have a process and a goal. Without setting goals, the tuning process will never end and it will likely never be successful.

No, you have to profile first. Profiling will tell you whether there is even any point in tuning, and, if so, what goals are reasonable.

Re:Process

[egoots]

No, you have to profile first. Profiling will tell you whether there is even any point in tuning, and, if so, what goals are reasonable.

It's a classic chicken and egg conundrum... If your program meets your performance requirements, why spend time profiling in the first place (but perhaps this is always necessary with Java apps).

I still believe that premature optimization is way too prevalent, unnecessary, and problematic. I recommend the following approach:

Make the program function correctly first

If it doesnt meet performance requirements, profile it to find out where the problems are

If necessary, optimize code highlighted by profiler

Re:Process

[adz]

There's no point in profiling if you've already met your goals.

He's right; you have to have a goal before a profile is of any use.
The profile may tell you that your goals are unreachable, but that's another matter.

What performance issues?

[Anonymous Coward]

Java has performance troubles? I thought we were all supposed to deny that. Did I miss a memo or something?

Pre-written appendix for Java Tuning

[OwnStile]

Anyone wanting to know about JAVA performance tuning should be sure to look at the time honored review of Why JAVA Sucks for Sysadmins .

Keith

Re:Pre-written appendix for Java Tuning

[josevnz]

This link is wortless. I'm a Sysadmin that use Java for SA stuff (just look for OpenNMS at http://www.opennms.org) and you will see than even with its problems Java is a good adition on your bag of tools. The best part of the article is the one that claims than OO is useless! :). JV.

Re:Pre-written appendix for Java Tuning

[egomaniac]

That article is the most absurd joke I have ever read. He spends half the article complaining about Java's startup time (which (A) does not apply in any server situation, and (B) is unfair, because you don't count the machine's bootup time when talking about the performance of C programs, do you?).

Then he invents other ways to talk about the startup time without seeming to talk about the startup time (for instance, trussing Hello World results in a ton of output, but naturally that's Java starting up and loading its classes. Again, do you consider what the machine has to do to boot itself up when you're talking about C programs?). I will point out again that Java's startup time is almost irrelevant, especially in a server environment (which is what he's talking about).

The rest of the article is picking on the "jar" tool. jar is a program written in Java. Criticisms against the jar tool no more reflect on Java than criticisms against gzip reflect on C. The fact that jar doesn't do a good job of reporting errors is (A) irrelevant, because it's a developer tool and we know how to read exceptions, and (B) still more irrelevant, because how well it reports errors has nothing to do with what language it was written in. Tons of C programs have lousy error reporting as well, such as a number of Unix utilities I might name.

Further, this article is obviously very old. He's talking about Java 1.1.8, which is what, five years old now? Might as well criticize Linux by talking about obscure video driver bugs that were fixed five years ago. Obviously, that's not the article's fault for having been written so long ago, but it is the parent poster's fault for bringing it up as if it is somehow still relevant.

Re:Pre-written appendix for Java Tuning

[Admiral Burrito]

Java exception verbosity is a serious problem. Many times I've heard of "java.lang" errors. The correct solution to this problem is to use C-style exception handling:

try {
// code
}
catch (Throwable t) {
System.err.println("segfault");
}

As you can see, Java is every bit as good as C.

Re:Pre-written appendix for Java Tuning

[hibiki_r]

Even though the page makes some good points, it's pretty hard to take seriously a page that uses the "100 times performace difference" between tar and jar. Try comparing with tar + gzip instead..

Re:Pre-written appendix for Java Tuning

[rutledjw]

You're kidding, right? Who says it's a problem? Heard from whom? Others (like yourself) that don't know java very well?

The exceptions are verbose, yes, but it's hardly a problem. Your example shows a lack of understanding, not of any empirical evidence.

If you like C so well, stick with it. I think that's the best solution

Re:Pre-written appendix for Java Tuning

[egomaniac]

I know sarcasm can be tough to spot, but he was kidding.

Anyone who suggests catching an exception and printing "segfault" as a solution is obviously kidding -- the intent, I believe, was to point out that verbosity is a much better fault then brevity in something like error handling. "segfault" is damned near the most useless message you can possibly imagine getting from a program, isn't it?

Re:Pre-written appendix for Java Tuning

[Frogg]

Um, C doesn't have any exception handling - that only arrived with C++

2nd edition?

[AssFace]

This is awesome! I am just getting back into a Java project again and wasn't aware that this book existed.

The only frustration is that I use safari.oreilly.com and love it, but they don't seem to have the 2nd edition from what I can tell... oh well - I'll add the edition that comes up in the search and that's better than nothing.

Insightful?

[rfischer]

Remember there is a distinction between client- and server-side Java. Java on the server makes me very happy.

Re:Insightful?

[rfischer]

as a developer, my friend. As a developer.

Java doesn't cut it

[AirLace]

We ported some of our internal Java business applications to C# for use with Mono, and emperical results already suggest the solution is several times faster than the Java code. The port was very easy, with each line of Java code mapping onto one line of C# or less. Porting the UI to Gtk# was more difficult, but we find the Gtk# code more maintainable and the UI, along with the Gtk+ WIMP plugin integrates much more nicely with Windows than SWING. We'll be investigating a switch to Linux over the next few months for some of our Point-of-Sales terminals as a result, and it should be easy thanks to the portability of Mono and Gtk#.

We also ported some of our backend tools for use with Mono. In use with the newly released Mono JIT runtime, Mini, we've achieved some truly stunning results. It turns out that some of the optimisations in the new JIT are better than those used by GCC, so once the code is loaded in memory, it performs better than raw C code. Although I don't yet have hard numbers to back up these result (the transition is still in progress), it has to be said that Mono is the real answer to Java performance. Being Open Source, we can also contribute back to the runtime to make it better suit our needs. It also plays nicely with RedHat 9's NPTL threading implementation, which is more than I can say for the current crop of Java JREs.

Re:Java doesn't cut it

[sbrown123]

We ported some of our internal Java business applications to C# for use with Mono, and emperical results already suggest the solution is several times faster than the Java code.

You could have saved yourself some porting by just compiling your java code with GCJ. GCJ allows you to compile your java byte code to native executables.


Porting the UI to Gtk# was more difficult, but we find the Gtk# code more maintainable and the UI, along with the Gtk+ WIMP [sourceforge.net] plugin integrates much more nicely with Windows than SWING.


Use SWT with Java. SWT uses Windows native widgets on Windows or GTK on Linux.


We also ported some of our backend tools for use with Mono. In use with the newly released Mono JIT runtime, Mini [ximian.com], we've achieved some truly stunning results. It turns out that some of the optimisations in the new JIT are better than those used by GCC, so once the code is loaded in memory, it performs better than raw C code.


Either your telling a big lie or dont have your facts straight. Unless you can show hard facts your not going to sway anyone into believing interpreted code outperformed compiled.


it has to be said that Mono is the real answer to Java performance.


Yes, if you dont mind porting existing working code.


Being Open Source, we can also contribute back to the runtime to make it better suit our needs. It also plays nicely with RedHat 9's NPTL threading implementation, which is more than I can say for the current crop of Java JREs.


What is exactly wrong with Java's use of native threads on Linux boxes?

Re:Java doesn't cut it

[AirLace]

You could have saved yourself some porting by just compiling your java code with GCJ. GCJ allows you to compile your java byte code to native executables.

This might become an option in a few years, but the GNU classpath is as yet not complete enough for our years. We actually didn't find gcj output that performant, despite it being compiled to native code. The JRE still beat it in many cases.

Use SWT with Java. SWT uses Windows native widgets on Windows or GTK on Linux.

We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target. It isn't really a cross-platform abstraction like WxWindows, and it's probably the reason why the Eclipse codebase is so large. You end up writing your application for each UI target platform. Gtk# runs and integrates with the platform instead, so you only write your code once.

Either your telling a big lie or dont have your facts straight. Unless you can show hard facts your not going to sway anyone into believing interpreted code outperformed compiled.

I did mention the results are empirical, but they're also pretty obvious from where I stand. You don't need benchmarks when something performs, in some cases, eight times faster than the original implementation. I may well put togther some benchmarks and post them to mono-list or linuxtoday.com. I don't have benchmarks yet; does that make me a liar? Sigh.

What is exactly wrong with Java's use of native threads on Linux boxes?

It's pointless to interface with the threads layer directly when pthreads exists. It makes the runtime essentially unportable to other unices/operating systems. Mono plays nicely with the environment, so the runtime can just be compiled on any POSIX-compilant system. Linux is great, but being attached to it so firmly that your application breaks when Linus changes some internal interfaces is not.

Re:Java doesn't cut it

[AirLace]

Sorry, that should be "for our uses".

Re:Java doesn't cut it

[Anonymous Coward]

Bwahaha, riiiight.

Sorry, but the C# compiler produces CLR bytecode. The JIT compiler runs at run-time.

With a Java JIT compiler you're running native code at run-time too.

Java and C# work the same way.

Re:Java doesn't cut it

[21mhz]

We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target. It isn't really a cross-platform abstraction like WxWindows, and it's probably the reason why the Eclipse codebase is so large.

I've seen the Eclipse codebase, and I'd like to hold you to an explanation. The only modules that are duplicated per platform are the SWT implementations and some minor stuff also tied to the platform (and abstracting it at that). The majority of modules is not platform-bound at all. Please explain what details of the public SWT API do you find non-portable.

I don't have benchmarks yet; does that make me a liar?

It makes your claims a bit hollow; trolls never back up their claims, hence you may be taken for one.

Re:Java doesn't cut it

[mritunjai]

I've been using eclipse and SWT for quite sometime.

We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target.

Complete BS !!

SWT offers a very high level of abstraction. If you want a still higher level of abstraction, then use the jface interface.

I've written a filesystem tool for QFS (QNX file system) and it runs without a single line of modification on QNX, windows and solaris!

SWT is a very sweet API. After using the utter crap that is Swing, its refreshing to see SWT. It uses native widgets so the app doesn't feel "out-of-place" !!

Combine this with the fact that SWT is as fast as any other GUI toolkit interface in a higher level language (higher than C/C++) and that its a filesystem tool, nobody ever suspects that its written in java !!!

And no dude, eclipse codebase is not huge... its not just another IDE as you think... its a complete platform!! You can write your own whole software platform using that baby!!

Re:Java doesn't cut it

[Glock27]

OK, all you "geniuses" that moderated the parent's parent up to +4 (incorrectly)...mod the parent of this post to +5 informative. :-)

While you're at it, the parent's parent (grandparent?) could use about 4 "overrated" mods.

TIA!

Re:Java doesn't cut it

[Headius]

You certainly are banking on Microsoft remaining benevolent toward Mono. I'm not sure why it's so hard for people to see that MS has absolutely nothing to gain from Mono becoming popular and widely used, except that it will draw people into the real .NET platform, which only runs under Windows.

Mono on Linux will always lag behind the Windows-based implementations from Microsoft, and Microsoft knows it. They've opened up the runtime, but not the class libraries that make the platform useful. The result is that Mono has to reimplement everything Microsoft has created, and try to match all the quirks, tricks, and undocumented behaviors therein. It's a losing battle.

I would love to see Mono as a viable, cross-platform, .NET-compatible deployment platform, but I truly believe it's a pipe dream. Mono could enable Microsoft's next-generation development platform, on which they are banking millions of dollars, to run without any ties to Microsoft itself. There's no way they would quietly sit by and let that happen. By keeping certain portions of the platform closed, patented, propietary, they keep their stranglehold on the whole ball of wax. People who like and become dependent on the n number of features Mono provides under Linux will very likely want the n+1 number of features that the bleeding edge Microsoft runtime and class libraries can provide. All roads in .NET lead to Microsoft.

Not to mention C# is the ugliest hodge-podge mix of C, C++, Java, and VB I could have imagined. Really guys, you don't need to change the name of keywords solely to be different. SAMENESS IS GOOD WHEN IT COMES TO CODE.

Re:Java doesn't cut it

[wirde]

I dislike Microsoft as much as the next geek, but I have to hand it to them when it comes to C# and .NET. I have not yet used it much to be honest, but what I have seen so far is great:

Clear and concise syntax (terser than Java, but still readable)
Posix style threads and sockets
Pointers are back (if you really need them)
(Much) better performance
Very easy to interface your code with code written in other languages (JNI anyone?)

Unfortunately, I fear Microsoft lawyers will come down on the Mono project like a ton of bricks when they least expect it.

1. Break Java by being faster (and sort of platform independent).
2. Remove platform independence
3. Profit!

Re:Java doesn't cut it

[Glock27]

We actually didn't find gcj output that performant, despite it being compiled to native code.

Really? One numeric (i.e. HPC) benchmark using gcj which was investigated in detail here on Slashdot (almabench) was within a few percent of the best gcc time...not bad by most folk's standards. ;-)

We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target. It isn't really a cross-platform abstraction like WxWindows, and it's probably the reason why the Eclipse codebase is so large. You end up writing your application for each UI target platform. Gtk# runs and integrates with the platform instead, so you only write your code once.

As another poster pointed out already, this is completely incorrect.

BTW, I look forward to your forthcoming benchmark. Be sure to post the code.

It's pointless to interface with the threads layer directly when pthreads exists.

Another whopper. All a Java user sees is the Thread (or Runnable) abstraction...which native or emulated thread library is used doesn't matter. IIRC, gcj uses pthreads if desired (yes it does, I just checked).

Looks like you're taking the "big lie" approach to attacking gcj... I look forward to head-to-head performance comparisons with the aptly named "Mono". (Its a disease as far as I'm concerned.;)

Re:Java doesn't cut it

[Glock27]

I see in the time it took me to post my last reply, the parent was modded up yet again, all the way to +5. What a travesty.

I hope people don't think Slashdot moderation ensures accuracy, it certainly doesn't. :-P

Inherent performance issues

[MSBob]

There are certain design decisions that were made by the java team that limit java's performance in a number of ways. Lack of stack objects comes to mind and collections that cannot store basic types.

That said for most network centric applications java is plenty fast. Now if we only stopped short of introducing the unbelievable overhead of XML's excessive verbosity...

Re:Inherent performance issues

[LarryRiedel]

Other things I think are major problems are inability to manage memory, lack of fundamental thread synchronization primitives and predictability, massive native (C) code impedance mismatches, and the enormous program (JVM) startup overhead.

JDK 1.5 should help with the JVM startup and threading problems. I hope someday for the ability to manage memory efficiently, at least letting me repeatedly resurrect garbage objects and get some sort of guarantees about when collection will happen.

Larry

Re:Inherent performance issues

[fforw]

lack of fundamental thread synchronization primitives and predictability, massive native (C) code impedance mismatches

Could you elaborate on those two points?

Re:Inherent performance issues

[LarryRiedel]

By "impedance mismatch" I mean efficiently calling C functions and passing parameters / return values,and sharing data structures like arrays and structs.

JSR 166 and JSR 133 address some of the thread issues.

Larry

idiots.;

[mandrake*rpgdx]

Why does programming languages have to be an either or situation? Everyone here assumes that anyone who programs in JAva does not know C/C++...why is that? Can't someone know multiple prog langs? I know many (too many too really list here) and find it asinine that people really think that everyone should just program in one lang.

Re:idiots.;

[iapetus]

Because the sort of people who like to get involved in discussions about whether C# is 'better' than Java or Java is 'better' than Perl or crunchy peanut butter is 'better' than textured masonry paint can't cope with more than one thing at a time, and tend to apply their religious zealotry with great vigour.

Those of us who can program in more than one language and know that sometimes it's a matter of choosing the right tool for the job (peanut butter for sandwiches, masonry paint for walls) tend to go through three stages:

1) Try to engage in such discussions on the premise that there's actual intelligent debate going on.

2) Discover ourselves becoming violently opposed to whatever rant we're reading at the time, writing tracts about how Java sucks when we're reading the work of a Java fanatic and drooling about the glory of Java when faced with a C++-toting moron.

3) Either give up in disgust and let the language fanboys get on with it, or sit on the sidelines and snipe at both sides - similar to stage 2, but more consciously applied. Normally that progresses towards giving up, though, since the zealots are just too easy and predictable...

Finally

[loserdave]

...another Slashdot book report.

More efficient != better

[brianjcain]

"Don't concatenate Strings, use a StringBuffer, it's more efficient."

Perhaps it is more efficient. I say, let the compiler do it for me. Code like this:

final String foo = frob + " noz " + baz.barCount()
+ " bars found";

is much more readable/maintainable than

StringBuffer fooBuff = new StringBuffer();
fooBuff.append(frob);
fooBuff.ap pend(" noz, ");
fooBuff.append(baz.barCount());
fooBuff.appe nd(" bars found");
final String foo = fooBuff.toString();

Re:More efficient != better

[Anonymous Coward]

That's not the kind of situation that's being talked about. In fact, that case is already done by the compiler.

final String foo = frob + " noz " + baz.barCount()
+ " bars found";

becomes

final String foo = new StringBuffer (frob).append (" noz ").append (baz.barCount()).append (" bars found").toString ();

The problem is when people do things like:

String s = "";
while (hasMoreData ()) s = s + nextCharacter ();

which becomes

String s = "";
while (hasMoreData ()) s = new StringBuffer (s).append (nextCharacter ()).toString ();

which has an extraordinarily higher cost than

StringBuffer b = new StringBuffer ();
while (hasMoreData ()) b.append (nextCharacter ());
String s = b.toString ();

Re:More efficient != better

[Jord]

Code like that may be easier for you to read it certainly is expensive for the system. The book example creates one string buffer. Your example creates three. Which is better?

Re:More efficient != better

[blamanj]

Actually,that's exactly what the compiler does. The problem occurs in cases like this:

String foo = "";
while (source.hasMoreTokens()) {
foo += source.nextToken();
}

where you are creating a destroying a large number of strings. In this case, using a StringBuffer is far more efficient and doesn't really harm readability.

Re:More efficient != better

[avandesande]

Totally agree. Unless you are doing bioinformatics routines or building multimegabyte docs, you don't need the string buffer. Might as well keep the server busy while you are waiting for that 30ms query to complete.

Re:More efficient != better

[joeykiller]

I agree! I've never understood why the compiler didn't do this behind the scenes, if concatenation is such a performance dog.

Recently I've looked into .Net and C# a little bit. I know that C# is inspired by Java, but that they've cloned this String (slow appending) vs. StringBuffer (fast appending) rubbish is a little too inspired if you ask me.

Re:More efficient != better

[bay43270]

Not only is the first example more readable and better maintainable, but it's much more likely to be optimized in future versions of the JVM (or compiler in the example you point out).

Even before string concatenations were optimized in Java, I used the plus operator. Everyone knew they would optimize it one day, and it really didn't slow anything down enough for anyone to notice (even timed tests had to be run into the millions to see a calculated performance difference in Windows).

By writing around the bugs in the compiler, people are creating code that will just have to be re-written with each new JVM release. Unless it's a noticable bottleneck, just write the code clean the first time and let Sun deal with it.

String/StringBuffer

[toriver]

It does under the hood whenever you use + for concatenation; this is why using String + String in a loop is ineffective: You create a new StringBuffer object per iteration. The solution in this case is to declare the StringBuffer outside the loop and use append() explicitly within.

For concatenating two strings, the concat() method can be faster than using StringBuffer, since it only needs to create a new char[] and do a (fast) arraycopy from the two internal arrays.

Also, everyone should be aware of the 1.4.1 memory leak associated with using StringBuffer's toString() and setLength() methods.

Re:String/StringBuffer

[bay43270]

It does under the hood whenever you use + for concatenation; this is why using String + String in a loop is ineffective: You create a new StringBuffer object per iteration. The solution in this case is to declare the StringBuffer outside the loop and use append() explicitly within.

I think your missing the point the parent was trying to make. Aren't there much bigger things to worry about than writing around bugs in the compiler?

Two years ago, everyone used StringBuffer.. today, everyone knows the use of the plus operator is as fast as it should be, so they opt for readability. Except people, who (like yourself) still use a StringBuffer when doing concatenation in a for loop.

Two years from now, the compiler will be optimized to use a StringBuffer *even* when the concatenation takes place in a loop. My code will still be readable (and run a tiny bit faster). Your code will run at the same speed and people will scratch their head - "why was he using a StringBuffer for concatenation?"

Why can't we just write our Java code as readably as possible, and then go back over it when we're done with an optimization tool looking for bottlenecks?

Re:String/StringBuffer

[julesh]

Why can't we just write our Java code as readably as possible, and then go back over it when we're done with an optimization tool looking for bottlenecks?

Because the compiler has to assume that the programmer knows what he is doing. I don't *want* the compiler to substitute my declarations of one data structure for another, even if it is almost equivalent in function. There are possibly reasons why you might not want to use a single StringBuffer for such a loop (for instance, StringBuffers tend to use a bit more memory than their equivalent Strings do... if you have a loop during which a long and complicated operation that uses a lot of memory is taking place you might not want a StringBuffer wasting large amounts of memory that the other calculation would need).

Besides, what's unreadable about:

StringBuffer buffer = new StringBuffer ();
while (some_condition)
{ // do some calculations
buffer.append("some string");
}
return buffer.toString();

?

J2SE has more coverage...

[drgroove]

"The J2EE performance chapters aren't as strong as the J2SE chapters. After seeing the statistics and extensive code samples of the J2SE sections, I expected a similar treatment for J2EE. Many of the J2SE performance practices still apply for J2EE (serialization most notably, since that his how EJB, JMS, and RMI ship method parameters/results across the wire), but it would be useful to fortify these chapters with actual performance metrics."

J2SE has more coverage, because this is the area where Sun is focusing right now on improving speed. J2EE has been fairly successful - also, since CPU, RAM, HD resources tend to be more excessive on servers than desktops, J2EE speed on the server isn't as critical than J2SE speed on the desktop. Getting Java-based desktop apps to perform as well as their C/C++ brethern is the 'holy grail' of Java/J2SE development right now, so the focal point of this book makes perfect sense.

Re:J2SE has more coverage...

[jrumney]

Speed on the server is more important than speed on the desktop. If you don't believe me, compare the average load on a server (typically 10-20%) with the average load on a desktop (typically 1-2%). The reason not much focus is needed on J2EE performance is that J2EE gets all the J2SE performance improvements automatically, and the J2EE containers tend to be written with performance in mind (or noone would use them).

Who cares?

[Elgon]

Okay,

flippant comment but let's think about this for a second: The majority of the time the alleged efficiency advantage is small or, as is generally the case, a pointless optimisation. Java coders seem to have the major efficiency/speed hangup - they use it to lord it over scripting programmers but they want/lack/desire the swiftness of C. (And yes, I do program in Java.)

To my mind, this is approching the problem from entirely the wrong direction: CPU time and CPU power are far cheaper than developer time and designer time. Therefore, rather than use some cobbled-together hack, use the standard implementations and take the performance hit.

This will be cheaper, probably 95% as efficient and, most importantly, be 195% easier to maintain or change at a later date. Consider the big picture rather than a single aspect.

NB - YMMV, for certain apps, it really does make sense to break all of the above ideas and principles, but if you REALLY need it to run that fast, you should be using C anyway.

Elgon

Re:Who cares?

[dubious9]

Please someone mod this up. I've been trying to say this for years, and perhaps never as eloquently. When you are managing 100K LOC (that's lines of code not library of congress), managers don't care that our programs run three seconds slower, but that they are saving heaps of money in development and maintenance.

Re:Who cares?

[Jord]

True, going back and fine tuning to gain a 2% speed increase (example) is a waste of time. However the value I see in books like this is in training/teaching the developer to write more efficient code the first go around. If you get out of the habit of doing String + String + String and use StringBuffers instead your code is more efficient from the beginning.

That is the value I see from books like this.

Re:Who cares?

[Randolpho]

Perhaps you should pick your examples better. Here's an exerpt from the StringBuffer JavaDoc:

String buffers are used by the compiler to implement the binary string concatenation operator +. For example, the code:

x = "a" + 4 + "c"

is compiled to the equivalent of:

x = new StringBuffer().append( "a" ).append( 4 ).append( "c" ).toString()

Granted, people should get in the habit of coding optimizations automatically, but in this case it's actually more efficient to do String + String + String; it takes less time to code than typing the method calls, and is easier to read/understand.

Which just brings me to my biggest beef about Java: no syntactic sugar. Operator overloading should be a part of Java, and bugger whatever the purists say. I want to save time typing dammit! :)

Re:Who cares?

[Jord]

I guess that is a poor example :) Going to have to read up on that one. I am curious as to when that was changed.

At least you got the point behind it.

I hope they never do operator overloading though, while it is easier for you, maintaining someone else's operator overloading is painful.

Re:Who cares?

[kp833]

java performance tuning?? its like saying how to make your tortoise run faster. hey tortoise dont look back while running.. helps you run faster. slightly bend your head. it more aerodynamic that way.. who cares!! when performace is an issue dont use java in the first place.

Re:Who cares?

[Capitalisten]

That really depends on what you're doing: If you're working client-side, then yes - performance is not likely to be that big an issue in most cases. However, working server-side (e.g servlets) is very different, especially if you're coding webapplications that may be serving a *lot* of users.

Of course you could write your high performance server-side application in C but then you'll loose your platform independence - and that could be a real bummer if you would like to migrate to a faster, more efficient platform because your current platform doesn't scale to the very popular website you were lucky enough to build. Or whatever.

Bottom line: Platform independence are very valuable in some situations and the way things may scale you have to maximize performance - and that's were tuning has it's place, even though it's time consuming in the first place.

Anders

Re:Who cares?

[evilpenguin]

I used to side with the purists. I've seen operator overloading so badly abused in some C++ programs that it is terrible.

But I recently had to write a Java program that did financial calculations (more rare, even in business software, than you might think). You don't want to use floating point (for all the classic reasons), and, in this case, you don't want to use integers because you need power functions for interest calculations and so forth.

The classic solution appears to be to use the BigDecimal class. I decided to wrap this in my own Money class that would include the financial functions and would also do currency conversions.

This kind of spcialized or "value added" numeric type is exactly where operator overloading should be available. Java would take a huge leap forward in utility if you could just overload the =, +, -, *, and / operators (= being assignment).

I understand why Java's designers did what they did. If they don't want to do this, then for goodness sake, do a hack like "+" support for Strings and "," support in for statements to give at least BigDecimal the basic operator set!

Or bite the bullet and give us operator overloading. I'm come around 180 degrees on this issue. I want my overloaded operators!

While I'm at it, let me trot out my favorite Java rant. Sun should LGPL or BSD License the entire Java SDK and APIs. (I actually think they should GPL it, but I'd settle for this). They are their own worst enemy. Java has a strong market position, and I don't think its going to go away any time soon, but it could completely destroy C# and .NET if some of the nagging problems could be dealt with by those who care. They are so concerned about "control" of the "standard" that they are endangering their de facto standard. Sure, there's gcj and kaffe, but why not just get us all working right on the real thing?

I would say the same thing about IBM's Java SDK, but I believe (someone correct me if I am wrong) they have some licensed Sun intellectual property in their SDK.

I actually worry about C# because it does support operator overloading. It is the only thing tempting about it to me.

Re:Who cares?

[maraist]

I'm unsatisfied by the idea that hardware is cheaper than developer time. Word Perfect alledgedly attempted to make a version in java, but scrapped it because of speed concerns.

If your product just barely runs within an acceptible time-frame, then you confronted with the probability that a given customer will agree with you. If a customer doesn't agree, then they will not use your product.. Thus while you save money on developer time, you lose potential customers (or existing ones). Worse, late in the game (after spending significant R&D time), management may decide to scrap the project when performance doesn't cut the mutards.

Yes, I realize that there are full-fledged GUIs written in java (Idea/eclipse/etc), but I definately notice their performance penalties (even on a 2GHZ machine with 0.5Gig mem). Moreover, the memory isn't enough to keep these monsters happy.

Now imagine a work-station runing a dozen java apps, each taking up a majority of the CPU. Current hardware can't even support this sort of environment without some hair-pulling.

Moreover, the idea that you can "throw hardware at it" assumes a certain level of parallelizability. Some problems are inherently serial and there is a definate max performance a single thread can achieve in a given generation.

Moreover there is an incredible danger in sacrificing performance to the hardware gods.

We're going to assume for the moment that we're talking about real developers here and that the idea of O(k), O(n) and O(nlog(n)) are religiously adhered to.

Assume that a given method is a k times slower than it could be for a given environment (where k need not be an integer; e.g. allowing 1.2). Now extend this process for an entire enterprise app.

Now realize that methods are generally part of loops, the delay is amplified. While the app may only utilize nlog(n), there are m such loops (where m grows as if n). Thus we have m^2 = (k*m)^2 => k^2.

Now if we only have k == 1.2, then we're fine, but since we have an interpreted environment, simple operation really take many times longer than equivalent c. Thus k is really 4 to 20 times it's conceptual cost. Thus k^2 => 16 to 400.

A java app has the potential to be 400 times slower than a c equivalent. Given the fuzzy numbers being used, I'll simply state that:
An arbitrarily abstract language is capable of producing sufficient values of k that there exists a level of complexity of code that will produce wait times that exceed the performance capabilities of a given hardware generation.

In short, we can get carried away in abstracting the hardware and overcomplexifying the software to the point of self-destruction.

One good example was an [unnamed] JDBC driver that wrote very elegant object oriented code but unfortunately accounted for 90% of the CPU and memory load of neighboring application. The overhead was small but subtle. Each component allocated and threw away objects.. Each such operation required potential garbage collection and initialization. There was never anything more than O(n), but there were several such O(n) calls within a single JDBC method invocation. The k's compounded enormously.

The thing is that you wouldn't really notice the overhead if you only accessed the JDBC once or twice. Unfortunately we happened to utilize jdbc calls in loops, which exposed the innefficiency. By using a different driver (which performed optimizations such as utilizing a static StringBuffer to avoid ANY memory allocations) the JDBC overhead became negligable.

The moral of the story is to identify (at design time) critical loops AND critically accessed sections and consider performance.. This is profiling 101, but I hear more and more java-developers arrogantly transcend such problems.

Re:Who cares?

[onash]

And what I don't understand is how we can talk about Java OO-purist when the primitive data types like integers aren't object and needs a wrapper to stick it in a container. That and working with Strings is what I don't like about Java.

I'm pretty sure that a modern compiler should be able to optimize things like that easily by now. If Sun is just holding on to old crap like that just because its old, then Java is doomed to be replaced.

but still I use Java because the IDEs like Eclipse and IntelliJ IDEA are so nice..

Re:Who cares?

[Elgon]

maraist,

a perceptive, informative and well argued post. I salute you. Perhaps I should have titled my post a little more carefully but it was written in between eating lunch and returning to work (I'm doing some Java coding amusingly enough.)

I agree with the point that Java is not the fastest language on the planet - windowing, for example, takes up a lot of time - but in these cases I wouldn't recommend the use of Java for just this reason. In such cases I would also argue that a 5% - 10% performance improvement isn't going to make enough of a difference, however there are certainly some cases where it will. If something is running that slowly then the chances are that your solution is a poor one.

The other thing I should have said in the first post is that optimisation for speed is not always a bad thing depending on the nature of the optimisation: Your example of looping is an excellent one - I rewrote one of my old perl scripts recently and managed to get an increase in performance of about an order of magnitude, simply by moving a complex hash declaration, which only needed to be compiled once, outside the main loop. This, I feel, is different from improvements to certain functions used in code, which are largely incremental in nature. The first is simply better design rather than tinkering with nonstandard ways of doing things.

I certainly would benefit from more exposure to profiling issues; how to spot them and deal with them.

Elgon

Re:Who cares?

[buckinm]

And what I don't understand is how we can talk about Java OO-purist when the primitive data types like integers aren't object and needs a wrapper to stick it in a container. That is a pain in the ass. Apparently though, 1.5 takes care of this...

Re:Who cares?

[ReinoutS]

Java would take a huge leap forward in utility if you could just overload the =, +, -, *, and / operators

Perhaps you should take a look at Jython. It's an implementation of Python in Java which allows you to execute Python scripts within Java code or to build Java classes with Python code. Since Python supports operator overloading and has a nice clean syntax it may well be helpful in your situation.

Re:Who cares?

[plierhead]

Therefore, rather than use some cobbled-together hack, use the standard implementations and take the performance hit.

This will be cheaper, probably 95% as efficient and, most importantly, be 195% easier to maintain or change at a later date. Consider the big picture rather than a single aspect.

Right on. Also, I know there are people out there building client-side Java apps that need blazing UI performance but I'd bet that 80% plus of the Java that gets written is server-side code that probably talks to an RDBMS.

As such, the real performance gains are to be made architecturally. For example, using some kind of caching mechanism to store reference data so it doesn't get fetched from the database every time. I can't count the number of times I've found people obsessing over the efficiency of some little algorithm when down on the next page their code is flogging the database server, where the cost of a single SQL statement can be counted in the many milliseconds and compltely overshadows any trivial gains to be had form using this type of list structure vs. that type.

Re:Who cares?

[snol]

ain't it the truth. The JDK and the fact that I can get at the (comprehensive, well-linked) API javadocs on the web anywhere, anytime are what make java worth using. Mod the man up.

Re:Who cares?

[jrumney]

It is true that CPU time and power are cheap in a desktop environment, but in a server environment, good attention to performance can mean the difference between a $2000 off the shelf PC and a $50000 server farm to support those 200 concurrent users. As for using C, then the developer time vs CPU time argument comes in (very few developers could outperform a good JIT compiler by hand these days, and even the tiniest memory leaks in a long running server process are real killers).

Re:Who cares?

[ElGuapoGolf]

I'm unsatisfied by the idea that hardware is cheaper than developer time. Word Perfect alledgedly attempted to make a version in java, but scrapped it because of speed concerns.

Sigh. Corel did this back in the mid 90s... Java was still very raw. I don't think Swing existed at the time. Half the tools necessary to do the port weren't around.
I'm tired of seeing Java taken to task for the half assed port Corel tried to do almost a decade ago. Let it go people. Let it go.

Re:Who cares?

[tealwarrior]

The first edition of the book addresses this point by noting that initial passes at performance tuning often yield improvements in the 100x speed-up range. Even with Moore's law generously applied not everyone should wait 7 years to get a performance level that can be achieve with a couple hours of tuning.

The first edition was useful in pointing out common performance pitfalls so when the profiler says some segment of code is taking a huge chunk of time you have an idea as to why and better yet, suggestions concerning what you can do about it.

Many of the performance pitfalls mentioned in the book have real benefits, such as String being immutable, Math functions running exactly the same everywhere by not using native implementations, and toLowercase working in other natural languages. Being aware of them allows you to get the benefits without taking the performance hit.

Putting you head in the sand and/or chasing memory bugs in C seems like a poor alternative.

Re:Who cares?

[julesh]

that Java is not the fastest language on the planet - windowing, for example, takes up a lot of time

That really is an issue of the AWT, not Java. My company has its own Java GUI class library (a port from an original C++ library that our developers were used to working with) that doesn't use AWT at all, and running stuff that uses that tends to have about 5* faster startup time and drastically improved responsiveness to AWT apps. Plus most of the people exposed to it find it quicker to develop the interfaces in the first place.

Java can be useful as a language separated from the baggage that normally comes with it...
although I suspect if C# had been around when we started we'd probably have gone that way instead (my boss likes MS software...).

I'm offended!

[Anonymous Coward]

It's Wednesday. Today we should have the weekly "XML sucks ass" -discussion, not the weekly Java bashing thread...

can any one validate this?

[mandrake*rpgdx]

I was looking on CNN and etc for a news report- couldn't find one.

Re:The original post is wrong, anyway...

[Jord]

Anything to back up that statement? Seems to me creating and destroying three Strings and three StringBuffers just to create one string is a waste and not efficient at all.

Please support your claim I would really like to see this since my experience is the opposite.

Re:Oxymoron ?

[Randolpho]

Amazingly, Java actually performs very well once the JVM loads. Sure, it can't match uber-efficient c code, but, let's be honest here, how much c code really is efficient? I'm sure it's less than c programmers like to believe. ;)

That said, "slow" performing Java GUI aps are not so much the fault of the platform itself as they are the fault of the Java programmer's inability to deal efficiently with threads.

Albatrosses

[colin_zr]

Want to kill the albatross?

Ick.

/. editors: please improve your literary references.

The albatross doesn't need killing -- it's already dead. The albatross was hanging from the mariners neck because he had killed it, and by doing so had brought bad luck upon his ship.

Quoting from memory here, because I can't be bothered to go find my copy of the poem:

"God save thee, ancient mariner,
from the fiends that plague thee thus.
Why lookst thou so?" "With my crossbow
I shot the albatross!"

...

Ah well-a-day, what evil looks
had I from old and young.
Instead of the cross, the albatross
about my neck was hung.

...

Oh happy living things! No tongue
their beauty might declare.
A spring of love gushed from my heart
and I blessed them unaware.

That self-same moment I could pray
and from my neck so free
the albatross fell off and sank
like lead into the sea.

As I said, that's from memory, so there are probably plenty of mistakes in there, but I'm sure a little googling will turn up a proper copy of the poem.

Killing the Albatross

[JahToasted]

isn't killing the albatross what got the ancient mariner into so much trouble?

Re:Killing the Albatross

[Henry V .009]

Best comment on the whole damn page. If there is justice, this will get an immediate +5.

Re:Don't use Java....

[vingilot]

Don't be an idiot. The size of the standard api does not relate to any inefficiency java has. How can the number of standard classes translate to inefficiency What is the magic number of standard classes to be "just right"?
The best thing about java is the richness of the api. And the size of the documentation. C++/C should take a page from java's book in this department.
You don't have to use the standard classes, go ahead and write the classes you need.

Jonathan

It's all about the VM

[slagdogg]

I read the first edition of this book completely. There are some good tips for extracting a few percentage points of improved performance. However, nothing has as profound an impact as simply using a better VM ... for example, many of my applications saw 25%+ speed increases simply by switching from the 1.2.x series VM to the 1.3.x series VM. Java does a pretty could job as a language of encouraging best practices, i.e. the inclusion of a standard StringBuffer. Extreme optimization at the code level will always be limited given the high abstraction of the language. However, extreme optimization at the VM level is a very real thing, and it doesn't take a whole lot of effort for the Java programmer.

Insightful!?

[Jerk City Troll]

Java isn't just about applets. In fact, applets are the least used feature of Java -- they're a neat little toy useage. Java is used primarily for back-end code now. Servlets talking to databases, for instance, are where Java is most often found.

Java is plenty fast

[ChrisRijk]

I've just been testing with a FFT benchmark I have, where I have both a Java version and a C version. Using GCC 3.2 on Linux, I've yet to be able to build a faster binary than what Sun's 1.4.2 beta JVM can do. IBM's JVMs are generally best at this type of benchmark, though Sun's been catching up fast, quite possibly passed them.

Even with CPU specific optimisations, advanced compiler options etc, the Java version is 30-80% faster than GCC's binary. (this is on both AMD and Intel CPUs) To get anything faster, you'd have to pay for it.

I also do server side programming, and I don't see why so many Linux users complain about Java's performance, while using/promoting Perl and PHP. If you want a high performance, responsive site, Java completely blows Perl and PHP away. I've only used JSP and servlets so far but they're all most web sites need anyway.

Re:Java is plenty fast

[be-fan]

The FFT benchmark is a very specific case. Once the JIT kicks in, it's not Java vs C++ anymore, it's the JVM optimizer vs the GCC one. Contrary to popular belief, the GCC optimizer is very good (check out benchmarks vs ICC at coytegulch.com). However, the FFT benchmark is a case where the additional information available to the JIT optimizer allows it to outperform native code. The whole benchmark is so small, it probably even fits in cache, and doesn't really stress any of the performance pitfalls of the language itself. Now, if you have a larger application, that doesn't consist of a single inner-loop, and meanders through a lot of varied code (ie. most real applications) then the performance story will be very different. At that point, Java's performance faults (excessive bookkeeping overhead, object allocation/deallocation, overhead from the JVM, etc) come much more into play.

Re:Java is plenty fast

[ChrisRijk]

The FFT benchmark is a very specific case.

Why? It's smaller than most code, but why does that inherantly benefit Java?

Once the JIT kicks in, it's not Java vs C++ anymore, it's the JVM optimizer vs the GCC one.

That's the whole point. Unless you only care about programs where the entire execution time is a few seconds, the JVM optimisation time isn't going to be much of an issue.

However, the FFT benchmark is a case where the additional information available to the JIT optimizer allows it to outperform native code.

I compiled specifically for the machine I was running on. I tried everything I could to make it faster than Java. For Java VMs, being able to get "additional information" is what always happens. It's not specific to the benchmark.

The whole benchmark is so small, it probably even fits in cache, and doesn't really stress any of the performance pitfalls of the language itself.

The code is 10KB file with a number of critical functions. A good optimiser would have to do inlinging, loop unrolling as well as a lot of data-flow optimisation. I ran it across a range of data sizes, and Java did better at bigger array sizes (until memory bandwidth was the limiting factor). You have it the wrong way around - the smaller the code/data, the more language specific issues show up.

Now, if you have a larger application, that doesn't consist of a single inner-loop, and meanders through a lot of varied code (ie. most real applications) then the performance story will be very different.

Unless your app's performance is dependant on I/O, OS calls or strings, making the application bigger is not going to make things very different. Actually, it can give JVMs a number of extra advantages due to the super-inlining capabilities available to run-time generated code.

At that point, Java's performance faults (excessive bookkeeping overhead, object allocation/deallocation, overhead from the JVM, etc) come much more into play.

I don't know what you mean by "bookkeeping overhead" but C code has to allocate/deallocate memory too, and has problems like memory fragmentation. How things compare with a garbage collector depends on the code, system, JVM etc, but modern JVMs can handle 10s of gigabytes of data in the heap. Simply to say that GC is slow is simplistic. Unless you have code that only runs for a few seconds, "overhead from the JVM" (if by that you mean the optimiser) isn't going to be a problem.

I'm not saying there's not areas where Java is at a disadvantage (I've listed some in this post). In some areas, it's going to remain inherant, but in others, JVMs are becoming advanced enough that issues like run-time optimisation can be a distinct advantage. Anyway, as far as I'm concerned, I have no problems with Java performance for anything I've done, including GUI code.

These days when writing highly optimised web-server code in Java, I have to get a super-accurate timer since Java's standard timer is only accurate to one millisecond, and that's too coarse grained to tell how much different various optimised I add make. This is where all the HTML is dynamically generated for each request btw.

Re:Java is plenty fast

[greenrd]

Troll??? The parent post is informative and correct!

Obviously moderated by some moron who thinks that Java is a purely-interpreted language and therefore "can't possibly be faster than C++". I have news for them: Java virtual machines have been compiling down to native code for about five years. GCJ wasn't very original or very clever, and there's no logical reason why it should necessarily produce faster code than a JVM, just because it does its compiling in one go. In fact, there's reason to believe that it would be less powerful, because it doesn't dynamically optimise at runtime.

Re:Java is plenty fast

[be-fan]

Why? It's smaller than most code, but why does that inherantly benefit Java?
>>>>>>
The reason it inheretly benefit Java is because of the characteristics of the Java language. First of all, it's a JIT language. Thus, if you have a tight inner loop, the JIT optimizer can optimize the hell out of it (even more so because it has access to runtime information that the static C++ optimizer does not) and just hand it over to the processor for execution. The JVM isn't even executed again until the loop is over. This situation doesn't invoke any of the language overhead that makes Java slow. This overhead takes many forms. The JVM has a large instruction cache footprint. Java objects all have an extra header containing type information that causes a data cache footprint and impacts memory bandwidth. The garbage collector can be a big problem. As Tannenbaum said, avoiding disaster is more important that optimal performance. The average case allocation/deallocation might be quite fast for a garbage collector, but when an actual collection occurs, you get that "disaster" that you're trying to avoid. The collection process thrashes the cache and occupies the application for a (comparatively) long time. When a function is invoked, the JVM has to check to see if the JIT has the code already cached. This takes time. Move beyond that to the Java APIs themselves. The Java APIs are designed for purity and ease of use. APIs like the C++ STL are designed for pure performance. For example, a dynamic cast is inherently slow, by the nature of the operation. Yet, the Java Collection APIs require them for every access. All Java class methods are by default indirect. Last time I measured (on a PII 300) indirect calls are about 10 times slower than direct calls. A small numeric benchmark doesn't hit any of these performance issues, but real application code hits them, hard.

Re:Oxymoron ?

[wfmcwalter]

I don't quite know what it is that they've improved, but JVM startup time seems to have gotten dramatically better somewhere betweek JDK1.3 and JDK1.4.1. On my mainstream winXP machine I can have a text-mode java HelloWorld running to completion in 0.2 secs (tested using cygwin's "time" command). That's a huge improvement over the several seconds it used to take, and makes writing little command line utilities in java a practical prospect.

Previously, the startup slowdown was due to the system having to load, verify, and link the twenty or so classes a simple program depends upon. Pjava and J2ME-CDC solved that by storing an image of the heap with the system classes already loaded, verified, and linked (and quickened) so the system was run-ready almost immediately. I wonder if the J2SE folks picked up on that? Alternatively, they could just be skipping the verify for those classes in the signed rt.jar, and offline preverify them prior to signature - the verifier always was the slow part of the process.

Your point about threads is well taken, and applies more generally to much of java programming. Java's language and libraries make it all to easy to write architecturally-slow programs - you really still have to fully understand what you're doing in order to write a decent program, regardless of the language.

Re:Sysadmins don't buy into this article.

[markv242]

I forwarded this article to our sysadmins, and they basically laughed it off. At least for web-based applications, almost none of these points apply. The article talks about the author's hatred of JVM startup times (which don't apply for an application server) and exception verbosity (which any real java developer will catch and deal with himself, rather than leaving it up to the sysadmin(?) to deal with).

I challenge you to make a C++/C# application that is thread-safe and can scale to millions of pageviews per day without writing a ton of supporting code. With a good J2EE app server, a java coder essentially just has to wrap his thread-unsafe code in a syncronized() statement, and he's done-- his app is now thread-safe.

Additionally, the "cross-platform doesn't matter for sysadmins" is a false statement; our CIO asked our net ops group "what would be the impact of us moving to an Intel platform?" and our sysadmins (after consulting with the coders) replied "absolutely no impact". That made our CIO very, very happy. Again, I challenge you to move your C++ apps from Solaris to Linux, or even to Windows, without any hiccup.

All of these other arguments are very specious: "I don't have enough RAM" will get you a reply of "go down to Fry's and spend $125 on another GB" every time. Processor speeds, even on Sun boxes, is getting to the point where the processor will never be a bottleneck for anything. Sure, java won't run as fast as a natively-compiled app. Neither will perl, php, tcl, or what have you. Raw processor speed is not as important when you have a couple of GHz to play with.

Java Deserves more Credit

[xRelisH]

First, I'm not a Java lover, however I have grown to respect the language. But, I would never ever want to be coding in it ( just preference and my feeling of lack of control ) . I'm currently a co-op for a wireless handheld device manufacturer (try to guess which one!) and I've learnt that Java, although slow has its merits. It's publicly known that we use a C/C++ based OS and optimized VM, and then on top of that we have our apps which are written in Java Micro edition. Although the apps are slower than our older c++ apps, we've found that the scalability really helps. We no longer need to have separate builds for each platform, and third/second party developers don't need to modify their software to have it run on our devices. It really simplifies things when you don't have to worry about CPU/chipset specific issues and worry about functionality, where the C/C++ guys (I'm in this group) can do all the hardcore work with the hardware. I'm curious to see what the next few reviews on this book say, as I'm sure some of the Java people here will appreciate it.

Re:Don't use Java....

[boomgopher]

Java would've been far better if they'd stuck to a few basic classes, and let people develop the classes they need as they go.

Well, gosh, you go right ahead and write your own replacement classes for everything that Sun has done already. What's stopping you?

That's exactly why I like Java. They have a lot of good built-in libraries that cover a wide-range of applications. I don't have to reinvent the freaking wheel every time I write an app.

Re:Don't use Java....

[be-fan]

Ugh. If C++ took the Java route, alternative operating systems would be impossible. C is so popular because it has a very minimal runtime system. Java is extremely difficult to port because of it's huge runtime. Java and C++ aren't really aimed at the same market. C++ is aimed at systems programming, where people can take the time to find the best external libraries for particular jobs, and need the performance of native code. Java is aimed (right now) at the server market, where having an quickly accessible, well documented (though not necessarily top-quality, if only because of the lack of competition) platform is more important. Personally, I think Java has more to fear from languages like Python (which have the extensive class libraries and are much more high-level to boot) than languages like C++.

Re:So

[machine of god]

heh. Actually, it got a score of one, because it's in your preferences. You add 1 to people who log in. See, for me, they don't get that. Also, AC's get negative 1 rather than zero. It works out well to weed out people like me and you, I think.

Re:Albatrosses [Mod parent up]

[SquareOfS]

Seriously -- actual intelligent literary reference on slashdot in a Java performance discussion. Who'd thunk it.

Also, if really quoting from memory, the author deserves some credit, since it's letter-but-not-punctuation perfect for the stanzas quoted, at least according to this source.

(Well, except for two missing lines in this stanza:
O happy living things ! no tongue
Their beauty might declare :
A spring of love gushed from my heart,
And I blessed them unaware :
Sure my kind saint took pity on me,
And I blessed them unaware.)

Native Code vs. HotSpot

[lenmaster]

I seem to remember seeing some benchmark that said that native compiled code was actually slower than the Hotspot JRE.

Can any confirm this and/or explain how this is possible?

Re:Native Code vs. HotSpot

[fforw]

I seem to remember seeing some benchmark that said that native compiled code was actually slower than the Hotspot JRE.

Can any confirm this and/or explain how this is possible?

well..

it surely depends on your definition of "faster". Java has a quite a start performance loss due to the initialization of the java-vm itself, class-validation etc.

So if you just fire up a C++ and a java tool, doing some expensive calculation and measure the overall execution time , c will be much faster.

( measuring java startup time in performace tests is like regarding the system boot for C++ performance. =)

But java has an advantage - hotspot compilation. It delays compilation for a while (e.g. 20000 method invocations) and uses heavy optimization techniques on the those parts of the code which proved to be the hot spots. It can rely on real usage statistics and can optimize things a static compiler couldn't. It uses massive method inling up to a degree only possible due to deoptimization (In case new code is dynamically loaded into the VM).

One benefit of method inlining is the saved method calls and bigger method blocks which can be optimized to a higher degree. On this the optimizer performs all the classic optimizations, including dead code elimination, loop invariant hoisting, common subexpression elimination, and constant propagation - plus some java specific optimizations like null-check and range-check elimination.

The longer your code runs - the faster it gets.

VMs will not be uniformly better as time goes on..

[alispguru]

The virtue and problem with Java is that it's a virutal machine. A lot of operations that are primitive at the Java byte code level eventually are implemented natively (and differently!) for each different virutal machine. This means that your optimizations for VM X may turn out to be pessimizations for VM Y.

Take threads, for instance - synchronizing primitives are cheap in a Java VM that fakes threads, more expensive in a uniprocessor machine with real threads, and still more expensive in a multi-processor implementation. Code that performs well on the simple VM may be a dog on the later, more-capable VM.

Storage management (garbage collection) is another example. There are a bunch of different strategies for garbage collection, with potentially different costs for creating primitive types versus class objects, class objects with no references versus those with references, etc. Some types of garbage may be almost cost-free in some VMs, and very expensive in others.

But, optimizing code for a particular VM/platform is exactly the thing that Java was supposed to free us from!

The most important advice this book gives is the stuff in Part 1:

Before you spend any time profiling, you have to have a process and a goal. Without setting goals, the tuning process will never end and it will likely never be successful.

Java performance is second priority for us

[snatchitup]

The bottleneck in our applications is not how fast whatever server-side language we use, and I imagine this is similar is most IT shops.

Our bottleneck is how fast we can execute lots and lots of stored procedures in our SQL and Oracle databases.

It really hasn't mattered if one of our coders has been terminating loops via try{}catch{}, or ending on a condition.

The most important thing has been, "Does each line, each method, each class do what it's actually supposed to do?"

Our bottlenecks have always been flow back and forth between different systems, including Lotus Domino, Oracle, MS SQL Server, Websphere, etc. etc.

Java is a small player in all this... C++, C#, Fortran, Lisp would not speed this up for us.

Re:Many Java projects rewritten in other languages

[egoots]

By the way - how much of Google or Yahoo is written in Java... let's see - none of it.

Every site makes their own choice of tools and technologies. Just because Google and Yahoo doesn't use Java, doesn't mean we can conclude it is useless

Also, where does the "Gig of RAM per web page view" figure come from?

Interpreted can be faster

[kmonsen]

The java bytecodes can be compiled at runtime, called Just In Time compilation. Since all the details of the current system are available at run-time it can be more optimized than it you are just targeting a platform. It is true that this is not done much in real life, but the theory is there. Note that JIT are not neccasarily platform specific, they just know the platform when run. The code for all the JIT compilers *CAN* be in the same executible. The parent post is for all I know correct in practise and mostly theory as well. This is just details that are seldom used.

Re:Sysadmins don't buy into this article.

[BalkanBoy]

.... which still does not excuse you from bad coding habits, poor algorithm choice, neophytic style of programming and a plethora of other things they taught you in CS school. I find the "RAM is cheap and so is CPU power" argument laughable, when it is spoken in the face of good efficient, programming. You should _always_ try to find the best (or most optimal, I should say) approach/solution to your problem. As soon as you've done that, you can use the "RAM is cheap, CPU power's cheap" argument, but not before that.

Let's do a linear search of every list we ever create in Java - 3Ghz is FAST! It'll find our value FAST! Instead of maybe doing a binary search on a pre-sorted list, right? Or let's always use bubble sort, it's fast on a 3Ghz CPU - forget quicksort, heapsort and the like.. too complex.

Re:Sysadmins don't buy into this article.

[markv242]

"You should _always_ try to find the best (or most optimal, I should say) approach/solution to your problem."

I disagree.

You should always try to find the best, most efficient, most cost-effective approach/solution to your problem.

If your internal time is billed out at $50 per hour, and you want to save your company money, you aren't going to spend 4 hours to create a custom garbage collector just to save another 5k of RAM-- you're going to go out and buy another stick of memory.

I agree wrt bad coding habits and the like, but everything has its price. If someone can push an application out the door rapidly that can still be easily maintained and only requires a bit more memory or a bit faster processor, I'm more than willing to expense the money for that new hardware.

Re:The original post is wrong, anyway...

[tgd]

Well, there are two ways you can prove it -- write a test... do a million iterations of one, versus a million of the other and watch your RAM usage and time it takes. Alternately, compile it and then use a java disassembler, and look at the resulting code. The string concatination is very heavily optimized, and structures like that where you are concatinating hardcoded strings basically does the equivalent of interning them (there aren't real string objects for those). Compilers are smart. If you concatinate to produce the string, it knows what you are trying to do and can optimize. If you self-optimize and get it wrong (which is what happens when you use a StringBuffer), it doesn't know what you are doing and can't optimize it. Two seconds of google searching turned up this, if you don't want to test it yourself: http://www.precisejava.com/javaperf/j2se/StringAnd StringBuffer.htm

Re:The original post is wrong, anyway...

[Jord]

Thank you for the link. I was interested in what you had found. Had no interest in writing test cases for this issue.

It was interesting to read though that the difference between the two is incredibly small.

Re:Albatrosses [Mod parent up]

[colin_zr]

Sure my kind saint took pity on me,
And I blessed them unaware.

Dammit. I knew some of those stanzas should've had six lines. Still, I'm pretty chuffed that I did as well as I did. :)

Once upon a time, I could recite the entire first part from memory. But, unexercised, that skill lasted only a fortnight or so before I started forgetting bits.

Anyway, I think this has strayed a little off-topic. But having spent the last few months coding in Java, I can say that Coleridge's poetry is a far more pleasant thing to be thinking about.

why this is inefficient in any case

[Submarine]

The classes of the Java standard library are, by default, thread-safe. This means that all methods that could cause race conditions are synchronized. Unfortunately, unneeded synchronizations are a major performance hit (it depends on the thread implementation).

So, whether you write s1 + s2 + s3 or rewrite this expression using a StringBuffer (which is, anyway, what the compiler does), you incur on most implementations a performance hit because the StringBuffer will be treated as if it could be shared between several threads.

Now, in this case, it would be sufficient to have a StringBuffer_unsynchronized class. In more complex cases, you would like to compile all methods with or without synchronization and have a system automatically switch to unsynchronized methods if it is safe to do so.

Unfortunately, telling whether it is safe to use unsynchronized methods is non trivial. Essentially, you have to know whether your objects may escape to other threads. Of course, as any nontrivial semantic properties, this is undecidable (which means there's no generic algorithm always giving the right answer to the question in finite time). There are whole doctorate theses written on such topics!

Re:Free Software in Java?

[javahacker]

I guess that means most of the Java programmers out there are busy doing development for money, especially J2EE development.

There are projects out there, just take a look on Sourceforge, but most of them are written to solve problems that Java developers have, not your average user.

In the Windows world, most inexperienced developers use something like VB, which is easy to write flashy, shallow applications in.

On Linux, where most of the Free Software developers hang out, many people have problems with the fact that Java is not Free (as in freedom) Software, although it is free (as in no money). For that reason, some developers refuse to work with it, just like some people refuse to use binary drivers from NVIDIA (or some other company).

The free implementations of Java are generally not up to the level of the ones from Sun or IBM, either in performance, or in language compliance. This may change in the future, since Sun appears to be moderating their attitude about Free Software implementations of Java.

Re:Many Java projects rewritten in other languages

[AndersDahlberg]

http://industry.java.sun.com/javanews/stories/prin t/0,1797,16725,00.html ,
http://industry.java.sun.com/javanews/stories/p rint/0,1797,23836,00.html

yada yada yada

Gig of ram per web view? You're totally clueless...

Re:The original post is wrong, anyway...

[greenrd]

Anyone who's ever done any performance testing in Java knows that these days, concatinating produces FAR more efficient code than the StringBuffer method...

Rubbish. Concatenating uses stringbuffers. See this post for an example of when manually creating stringbuffers is more efficient.

Another explanation for performance increases

[zipwow]

Since other posters have already indicated that gcj /does/ lead to better performance, I think I have a cause for your performance increase beyond "Java sux":

Re-implementation removed the bottleneck.

What kind of profiling did you do against your original Java application? Where was the time being spent? I've worked on some pretty high-performance java applications, and have found them to be quite scalable.

If you're talking about GUI responsiveness (not client/server or high processing interactions), then you may have a point. All the nefarious interactions between the platform-specific GUI toolkits and their OS of choice (this applies both to Windows and Linux) do a lot of very specific optimizations that just can't be done as well cross platform.

Interestingly, the original AWT used components based on native ones for just this reason, but that turned out to be problematic.

Anyway, if you have the intention of supporting your claim that your application had performance problems due to Java itself, I'd be interested in hearing about your profiling process.

-Zipwow

Re:Another explanation for performance increases

[Glock27]

Interestingly, the original AWT used components based on native ones for just this reason, but that turned out to be problematic.

AWT was a fairly poorly designed library. As I recall, it was designed at Sun in something like two weeks.

At any rate, SWT seems a much better job, also using native widgets.

Re:Sysadmins don't buy into this article.

[pmz]

If your internal time is billed out at $50 per hour, and you want to save your company money, you aren't going to spend 4 hours to create a custom garbage collector just to save another 5k of RAM-- you're going to go out and buy another stick of memory.

This reminds me how broken many (most?) corporate accounting systems are. Where I work, for a stick of RAM (or software, or whatever), it would take at least four hours spread over a couple weeks just to figure out who to submit the request to, wait for our "purchasing agent" to get a couple signatures from bureaucrats, wait for the purchase order to work its way to the top of a pile, and finally get the RAM only to discover they ordered the wrong type. All the while, they'll happily pay for labor hours wasted on slow computers with inadequate RAM (for example).

Why there is such a fundamental disconnection between spending money on labor versus spending it on time-saving equipment and software leaves me questioning reality.

just-in-time compilation

[Submarine]

"interpreted code outperformed compiled"

All modern JREs have a JIT compiler, which compiles frequently used functions to native code. It is possible that the JIT compiler in the JRE is better than gcj.

From a more general point of view, it is possible for JIT compilation to optimize better than ordinary compilation. This is because the JIT compiler has access to dynamic profiling information that is not available to the "normal" compiler (though you can feed profile information from benchmarks to some "normal" compilers - but these benchmark profiles may not fit the dynamic load).

Re:Free Software in Java?

[greenrd]

Um... ImageJ (public domain)... also check out http://dmoz.org/Computers/Programming/Languages/Ja va/Applications/

really.

[mandrake*rpgdx]

becuase i know c, c++, asp, php, perl, ada, python, lua, java, delphi, pascal, object c, visual basic, qbasic blah blah blahitti blah blah blah and i have to say i like proggin in java from time to time. i know alot of other people that do as well...and really, if it's compiled source (which is what you are comparing it to, correct, compiled C source? I'm not talking about JIT compilers but something like a true binary compiler (which exists, mostly as a GCC ext), Java is not much slower than other higher-level languages.

I'm soooo sick of language snobbery.

and by efficient you mean? *n/t

[mandrake*rpgdx]

NO TEXT! BIYATCH!

Blah blah performance tuning...

[Lardmonster]

So people write their own versions of linked lists and strings, to get up to 15% performance improvement. Well whoopie-fsck.

How much does that extra development time cost?

Writing ones' own java.lang.String takes time. Writing routines to convert com.donkeybollocks.String to java.lang.String and back again takes time. Supporting it takes time. And time is money. Me, I'd rather spend an extra £100 on a faster processor, or a Gb of RAM, and take a 25% performance improvement.

Come on guys, one of the major wins of the OO methodology is code reuse. Time was when programmers would always have to write their own I/O routines - I thought those days were long-gone. Rewriting fundamental parts of the Java API is just plain silly, unless it has a bug or a serious limitation (eg, it's non-threadsafe).

Re:Java performance is second priority for us

[TheLink]

I'd thought a major bottleneck would be attending all those meetings... :)

Re:Sysadmins don't buy into this article.

[Bodrius]

I don't know what pletorah of things they taught you in CS school, but much of the wisdom they taught some of us can be summarized:

- Big O matters. Optimization of constants is an expensive luxury.
- Reimplementing the wheel for the sake of marginal efficiency is a sure way to get a square and inefficient wheel.

Most algorithms of any common use are provided in the standard libraries of each language. If not there, any algorithm can be implemented in any language by virtue of its Turing-completeness. This guarantees you bigO efficiency, which is what matters in the long run.

The article complains about Java being slow for the sake of its pcode nature. That's a constant factor, not bigO. It's automatically defeated by "CPU is cheap, RAM is cheap", i.e.: constant factor acceleration is cheap.

You better have a good reason to worry about constant factors: if your program demands so much from the machine that the constants make the difference on whether it's practical or not, you better be experimenting with the 'bleeding edge' or there's something really wrong with your program.

Efficient algorithms are used on every language by any programmer worth 2 bucks. Java has the advantage of implementing a bunch of them on standard libraries that work quite well, thank you. Someone who uses bubblesort in Java outside of a classroom is not lazy, he's an idiot. Implementing bubblesort is more complex and expensive than calling Arrays.sort().The same thing actually applies to any programming language.

If your concerns about speed as a typical sysadmin (servers and workstations) or even worse, as a developer, are dominated by constant factors, it's time to go back to take data structures and algorithm analysis at CS school.

99% for me.....

[luggy]

Sounds like this guys really done his homework, but if timing is that critical ask if java should be your first choice.

I primarily use java, both for work and home projects, and I have to say that I have almost no performance issues with java. I think that the way CPU speed has increased (and will probably continue to do so) that bytecode interpreted languages now have less of a performance gap againts native compiled code.

Profiling as Early as Possible

[ldesegur]

I personally use Optimizeit Suite for Java development from Borland software as early as possible in the development cycle. This gives me an edge to keep the code fast and efficient without too many efforts. Including the profiling process in your development cycle avoid big surprises that you have to fix even if it's sometimes too late to revise your programs. Performance sometimes involves re-evaluating algorithms and that can't be done in code freeze. As it turn out, then even have a profiler for .NET that has just been released.

Re:The original post is wrong, anyway...

[fforw]

well.. the linked article features three benchmark comparisons between concated and StringBuffer.append()ed Strings. One is won by concat. Two are won by StringBuffer.

The one which ends in favor for concat is :

String result = "This is"+ "testing the"+ "difference"+ "between"+
"String"+ "and"+ "StringBuffer";

contra

StringBuffer result = new StringBuffer();
result.append("This is");
result.append("testing the");
result.append("difference");
result.append("between");
result.append("String");
result.append("and");
result.append("StringBuffer");

which I wouldn't even code after some days without any sleep.

Guess I'll keep using StringBuffer.append()...

Re:The original post is wrong, anyway...

[tgd]

Um... Not to get into a pissing match, but you've clearly never tried it. Concatinating does NOT create string buffers...

But this is /., heaven forbid anyone try something before they reply, right?

Random performance finding

[Wordman]

Semi-on topic: a while ago, I gave some thought to pooling StringBuffer objects to improve performance. Bad idea. This page explains my findings.

You are completely wrong

[tijsvd]

Your example is utter nonsense. If the most-run method of your application becomes a factor k slower, your application will at most become a factor k slower. Never k^2 or whatever.

It does not matter at all if this method is in a n, n^2, exp(n) or even exp(exp(n)) loop, since this relates to the size of the input problem. During the program, the method will be called some number of times (say x). If the method first cost u time, then after changing it, it wil cost (u*k) time. Calling it x times will take (u*k)*x = (u*x) * k time. So you are still slowed down by a factor k.

Now let's look at the problem size. If complexity is n^2, then doubling your problem size will increase execution time by a factor 4 (2^2). If the method is slower, and we double the problem size, execution time will still increase with a factor 4, since the complexity itself does not change. If we compare the two double-size problems, there is a factor k between them.

Don't try to bazzle us with mathematics if you can't handle them properly.

open src the sdk and apis

[Glass of Water]

Excellent rant, man! I agree totally.

Re:Sysadmins don't buy into this article.

[kasperd]

Turing-completeness. This guarantees you bigO efficiency

I agree that bigO efficiency do matter, and you can do that in any half-decent language. But you cannot do efficient programs on a Turing-machine, you will often add a linear factor to the time usage by implementing it on a Turing-machine.

Implementing bubblesort is more complex and expensive than calling Arrays.sort().

Reminds me about the first book I read about assembly code. It started explaining that performance was one of the reasons to write assembly. The first code example was an implementation of bubblesort. (Duh!)

Re:The original post is wrong, anyway...

[jrumney]

You've clearly never tried it in the real world. All the textbook examples I've seen involve concatinating String constants. In the real world, you just don't do that. The whole reason you need to concatinate those strings is that you did not know at compile time what they were going to be. In that case, the best the compiler can do is use String.concat(). If more than one concatination is being done, a properly initialized StringBuffer will be faster.

New math?

[Trinition]

OK, so I was curious, so I checked up on this. Maybe I'm wrong, but I don't see 64 bytes. Here's a reduced snippet of the member variables in a String class (1.4.1_06):

public final class String
implements java.io.Serializable, Comparable, CharSequence
{ /** The value is used for character storage. */
private char value[]; /** The offset is the first index of the storage that is used. */
private int offset; /** The count is the number of characters in the String. */
private int count; /** Cache the hash code for the string */
private int hash = 0;

There are 3 ints, and a char array. each int is 4 bytes, the reference to the array is 4 bytes, and the array has a length attribute (another int) that is 4 bytes. That's 3*4 + 4 + 4 = 20 bytes. Then you would add 2 bytes for each character. But an empty string would be 20 bytes by my count.

Where did you come up with 64 bytes?

Re:New math?

[Trinition]

Granted, I forgot about some of the other overhead. There is the class pointer, among other things, that Java uses to remember what type of object everything is. Still 64 sounds high, but it is less important too as the size of a String grows.

Thanks for the tip, though! I wasn't criticizing, but I did want to know where 64 bytes came from!

Re:New math?

[Anonym0us Cow Herd]

You only need 4 bytes to make reflection work. Each object has a pointer to what class it is. The class information has everything else, the vtable so to speak, what interfaces are implemented, etc. All String objects have one single pointer to a common String class object the defines what a String is, what its members are, what its methods are, etc. everything needed for reflection. Think of the vtable as being more than just an array of method pointers, but meta information (the class object) about the object. More than just a vtable. Therefore, reflection requires no overhead really, since an OO language needs a vtable pointer.

Re:New math?

[julesh]

There's an additional 16 bytes involved in the object class descriptor pointer and the reference to the object's monitor (*2 - one for the String and one for the char[], which is a fully fledged object in its own right), plus probably a couple of bytes overhead for the memory allocator. About 32 bytes seems reasonable. I think the point to make is, though, there is no _sensible_ way of making the string any smaller without sacrificing performance. Plus the objects have the ability to share the array between two strings that have similar data (say one is a substring of another) and that _substantially_ reduces memory requirements. I'd say the Java string implementation is about as good as it gets.

Re:A warning sign

[dracocat]

Agreed.
Lets just remove needless things such as:

• Genericity
• multiple inheritance
• assertion

oh yeah, they already stripped those out before it was ever released.

Actually I would much rather see a slower JVM and be able to have at least multiple inheritance. But alas, I am stuck with workarounds invloving interfaces.

The huge market for Java tuning books is probably more acurately attributed to coders' over emphasis on software tuning.

Tuning should be done wherever most time is spent in the software, not just willy nilly where a book tells you too.

Re:Don't use Java....

[ChannelX]

The size of the runtime really is irrelevant to porting Java to a given platform since the majority of the runtime is java class files. The part that needs to be ported is the VM and any other native stuff (which isn't much).

To all people claiming speed doesn't matter

[Glyndwr]

I've seen a lot of responses in this thread from people saying "bugger CPU time, just spend a few hundred dollars on more/faster CPU/RAM. Dev time is expensive!"

Well, yes it is, but it's not always that simple.

I have a Java app here I'm performance tuning for my PhD that allocates frequency hop sets to mobile phone networks. Running on a 2.2Ghz Athlon wih 512Mb RAM for a 15-transmitter test case takes an hour, it scales exponentially with transmitter size, and I want to address a 458 transmitter case. It's about 10^500 calculations, or it was before I started improving the algorithm. Even so, it's still going to be billions of iterations through the inner loop. Even a 1% speedup is hours off my runtime and that's a big thing for me.

So when you dismiss all performance tuning with a wave of your hand, remember us poor beleagured scientists. We actually need all this stuff.

Not a bad albatross

[jemenake]

Performance has been the albatross around Java's neck for a long time..

Every time some C/C++ snob snipes Java for being slow, this is what I tell them:

When I write a Java program... if it's too slow today, then, in time, the problem will go away without any more effort on the part of the programmer. In a year from now, we'll certainly have faster computers, which will make up for any speed problems.

On the other hand...

A year from now, we will almost certainly not have CPUs that are suddenly immune from dangling pointers and memory leaks.

In other words, there are not plausible, near-future-forseeable advancements in computing hardware that could fix the worst problems of C/C++. Meanwhile, the near-future advancements in hardware are almost guranteed to fix Java's worst problem.

The same holds true for doing your computing today... regardless of what hardware is available a year from now. Personally, I'd rather have a slow program that could keep running than one that was really fast, but crashed before I could save my work.

Re:Not a bad albatross

[Kj0n]

The same holds true for doing your computing today... regardless of what hardware is available a year from now. Personally, I'd rather have a slow program that could keep running than one that was really fast, but crashed before I could save my work.

That may be true for you, but the success of MS proves that most people prefer a slow program that crashes before they can save their work.

Re:Don't use Java....

[be-fan]

1) *The* Java VM is very difficult to port. Java VMs in general aren't, but if you want something that is performance competitive, you need one of the big ones. This is a pain at the application level, but would suck for a systems-level language like C/C++.
2) C/C++ doesn't have the benefit of a portable runtime. If it had a giant class library like Java, you'd have to port a whole lot of native code.

This is nothing to slight Java. For the places where Java is used, the large runtime isn't a big disadvantage. But C/C++ is used in very different places than Java.

Re:Don't use Java....

[AndersDahlberg]

"1) *The* Java VM is very difficult to port. Java VMs in general aren't, but if you want something that is performance competitive, you need one of the big ones. This is a pain at the application level, but would suck for a systems-level language like C/C++."
I think you're confusing the *java vm* with the *java runtime environment*, e.g.

http://java.sun.com/docs/books/vmspec/2nd-editio n/html/VMSpecTOC.doc.html - approximately compiled (on win32 platform) to << 1mb dll's (could probably squeze it into << 100kb if you wanted to remove some parts- e.g. CDC, using SWT instead of Swing + AWT etc.). If you consider porting this rather few native files hard... ok, so be it - and

http://java.sun.com/j2se/1.4.2/docs/api/index.ht ml - runtime environment which consists of "pure" java classes that when necessary binds with these earlier mentioned dll's. - this classes needs not be ported at all (don't mention bugs please - remember WORA ;)

Quality...

[FatSean]

Why did the thread bitching about + vs. append() get so many points?

Re:Quality...

[Bodrius]

Now there's a good question.

After all these years of Java hype and Java development, compiled vs interpreted, VM vs cold steel, one wonders why all this deep and complex discussions about "performance tuning" end up being mostly about String and StringBuffer.

I mean, yes, it's an important tip for the beginner, but surely there are more and newer insights to the matter!

Re:A warning sign

[tunah]

Assertions are in 1.4. You use a statement like "assert ;". This is an incompatible change, so you must compile with "javac -source 1.4". To enable assertions at runtime, run with "java -ea".

Re:Don't use Java....

[be-fan]

I can't find any of your numbers at the Sun sites you linked to. I'm talking about porting the HotSpot or the IBM VM. Those are most definately not less than 1MB of code. The HotSpot VM is more than 235,000 lines of code. For reference, that's about as large as the non-driver core of Linux 2.0. Imagine writing trying to write an OS in C/C++ and having to port 235,000 lines of code first!

Re:Sysadmins don't buy into this article.

[TummyX]

challenge you to make a C++/C# application that is thread-safe and can scale to millions of pageviews per day without writing a ton of supporting code.
With a good J2EE app server, a java coder essentially just has to wrap his thread-unsafe code in a syncronized() statement, and he's done-- his app is now thread-safe.


LOL. Firstly C# has a "lock" statement and C/C++ have libraries with similar functionality.

Secondly, you know nothing about concurrent programming. Simply locking a bit of code doesn't suddenly make your program "thread safe". Get a clue.

interpreted is bad enough

[xpl_the_myst]

That Java is interpreted is bad enough compared to compiled languages like C. Just imagine the situation within a loop - suppose there is an access of a class' data member. The interpreter / JVM reads in this instruction, parses it and executes it within its own space. Imagine on the other hand what compiled code would do - the class.value thing would be traslated directly to a memory address. And loading code is done by the processor. Everything is some orders of magnitude faster. And this whole thing is in a loop that might run a zillion times. I know most people around know this, but I was trying to describe it in its full glory so that the optimisations that all these posts are discussing look powerless.

So optimisation for Java will, most probably, not do much. But still, it makes sense to make it as fast as it can get. In this context, it has to be pointed out that the development of faster and faster C compilers was spurred on by a lot of academic research. That was the time when those things were still new and hot. Now, I doubt if that magnitude of research goes into JVM & javac optimisation.

Re:A warning sign

[dracocat]

Wow. thanx.. And I thought I never learned anything from /. Thanks.
Any idea of when multiple inheritence will be introduced? 2.x?

Re:A warning sign

[Rocko]

Genericity will be in 1.5

Re:The original post is wrong, anyway...

[greenrd]

"Um... Not to get into a pissing match, but you've clearly never tried it."

Yes, I have. And I tried again just now to check if it had changed. Sure enough, it still uses StringBuffers:

System.out.println ("Output is: " + a + ", " + b + ", " + c);

is translated to:

34 getstatic #8 <Field java.io.PrintStream out>
37 new #9 <Class java.lang.StringBuffer>
40 dup
41 invokespecial #10 <Method java.lang.StringBuffer()>
44 ldc #11 <String "Output is: ">
46 invokevirtual #12 <Method java.lang.StringBuffer append(java.lang.String)>
49 aload_2
50 invokevirtual #12 <Method java.lang.StringBuffer append(java.lang.String)>
53 ldc #13 <String ", ">
55 invokevirtual #12 <Method java.lang.StringBuffer append(java.lang.String)>
58 aload_3
59 invokevirtual #12 <Method java.lang.StringBuffer append(java.lang.String)>
62 ldc #13 <String ", ">
64 invokevirtual #12 <Method java.lang.StringBuffer append(java.lang.String)>
67 aload 4
69 invokevirtual #12 <Method java.lang.StringBuffer append(java.lang.String)>
72 invokevirtual #14 <Method java.lang.String toString()>
75 invokevirtual #15 <Method void println(java.lang.String)>
78 getstatic #8 <Field java.io.PrintStream out>

It even uses StringBuffers if you just have "foo"+b.

Of course if you use constants the compiler can automatically concatenate them together into a single string in the .class file... but that's a special case.

Re:The original post is wrong, anyway...

[tgd]

Eh, try again. Should've tried the alternate...

Here's a comparison of the two methods:

12 new #4
15 dup
16 invokespecial #5
19 ldc #6
21 invokevirtual #7
24 aload_1
25 invokevirtual #7
28 ldc #8
30 invokevirtual #7
33 aload_2
34 invokevirtual #7
37 ldc #8
39 invokevirtual #7
42 aload_3
43 invokevirtual #7
46 invokevirtual #9
49 invokevirtual #10

Versus

56 invokespecial #5
59 astore 4
61 aload 4
63 ldc #6
65 invokevirtual #7
68 pop
69 aload 4
71 aload_1
72 invokevirtual #7
75 pop
76 aload 4
78 ldc #8
80 invokevirtual #7
83 pop
84 aload 4
86 aload_2
87 invokevirtual #7
90 pop
91 aload 4
93 ldc #8
95 invokevirtual #7
98 pop
99 aload 4
101 aload_3
102 invokevirtual #7
105 pop
106 getstatic #3
109 aload 4
111 invokevirtual #9
114 invokevirtual #10

Boy, its a damn good thing you went out of your way to both write more code and generate slower code. Now maybe its a fluke of the JVM on here, but doing the concat method is 20% faster...

fuck off

[mandrake*rpgdx]

yup, that's it. go fuck yourself.

Re:A warning sign

[tunah]

I think multiple inheritance is out by design, too unsafe/unpredictable i guess. I haven't actually gone far enough into C++ to use it, but it would seem to make things less "safe" - the thing that keeps me using java is its predictability.

Re:Free Software in Java?

[wglass]

The Jakarta project at http://jakarta.apache.org has dozens of high quality free software products. Surprises me that no one has mentioned this.

The best is Apache Tomcat, a high performance app server and the reference implementation of the JSP/Servlet standards. Other highlights include Velocity (templating language), JMeter (web performance testing), Torque (O/R mapping) and a number of development libraries.

Re:Java performance is second priority for us

[jebintx]

We found the same thing. Database access was magnitudes more time consuming than a bubble sort vs. quick sort. We used this tool Ironeye to capture and time everything the app was sending to the db. Fixed some ugly problems as a result... Biggest lesson: combine queries. Which sometimes requires not encapsulating or initializing data objects in quite the same way.

Anyway, it's good to know what your app is actually doing to the db. IE basically just swaps your JDBC driver and captures all the driver's interactions with the db.

Re:The original post is wrong, anyway...

[greenrd]

You forgot to preview before posting!

Anyway, I now realise we may have been talking at cross-purposes. In Computer Science, "concatenate" is a general term for adding one string to the end of another, whichever way it is implemented. Therefore, I thought you meant "a+b". I didn't realise that you might have meant "a.concat(b)". You could have been more clear.

Re:Sysadmins don't buy into this article.

[plastik55]

If your application written in C runs, say, 20% faster than Java on the same machine, then when next year's hardware comes out it will *still* be 20% faster. You will save 20% when purchasing hardware to run the application, and that 20% gets applied to all your hardware purchases in the future. Not to mention the marketing advantage of efficiency if there are competing products.

Contrary to your CS conventional wisdom, the difference adds up in many cases when you are talking dollars and cents. It doesn't just apply to the "bleeding edge."

Re:Cost of Java Performance

[Tukla]

I've never heard this assertion before. Got a cite?

How do you "rip off" something in the public domain? Doesn't "public domain" mean "no copyright"?

Re:Sysadmins don't buy into this article.

[Bodrius]

20% sounds like an inflated number. The typical app spends most of its time waiting for I/O or doing silly stuff for user interaction. A 20% overall difference would imply what, 50%, 100% slower when it's actually working?

There's some overhead, but it's never that bad. Sure, the overhead matters, which is why there's an investment on improving VM technology, providing access to native operations, etc.

But also the worst overhead offenders are not VM issues, but application design issues: blocking I/O, threading bugs, NOT using multithreading when you should, etc. Also, using Swing/AWT in a non-trivial GUI. I'm beginning to consider Swing/AWT just a giant bug.

However, let's assume the 20% speed difference in an application...

It's not that constant factors don't matter at all, it's that they matter the least. And when you have so many more important problems to fix, they take the last place in the priority list.

By definition, choosing your implementation language is an early decision that takes place long before that list is filled up. Although speed is always a concern, algorithmic speed is more important than PL speed, and independent of it. So PL speed shouldn't have that much to do with the decision.

Saving 20% in hardware is great, and the efficiency marketing advantage is important too. But those advantages are worth nothing if your application is buggier, less extendable, less flexible than your competitors, and specially if it gets to the market AFTER your competitors.

Developing applications in C is more expensive and complicated than developing them in Java, and the difference is typically more than the difference in speed. (I'm not saying that C applications are inherently worse than Java apps, just that to develop the same application with the same extensibility, features and stability takes more time, and a bunch of non-standard libraries).

Development costs add much more quickly than hardware costs, and unlike hardware costs, development costs are not guaranteed a return in performance. These are not dollars and cents, but hundreds and tens of dollars: development is more expensive than hardware.

Then you go to the client 6 months after your competitors and try to sell them the application. If they haven't already bought from the competition, you'll try to convince them that although your application is more expensive, and altough it hasn't been tested in the market for as long as the other ones, and although they'll need a C programmer versed in your favorite non-standard libraries to maintain it (you do give them API documentation and the tools to maintain it, right?), your application will save them a few bucks in hardware.

Unless the difference in hardware costs has more than 4 digits, I think your customer will advice you to take an accounting class.

If the difference is more than 4 digits, you are pushing the technology and you need to care about constant factors.

Either that or you're not dealing with a typical application. For example, a scientific analysis program that spends most of its time in pure computation needs all the juice it can get. Although I understand Java works fine for pure computational tasks.

Now, if you can make your applications in C as cheap, fast, and safely as with Java, then you have great C developers so you should just keep doing that. Most people can't.