Lies or Statistics?

Posted on Wednesday 23 January 2008

I have been hearing some buzz in different news sites about how slow Java is. There have also been a few people that I have run into in the past month that have been asking about it. Where is this coming from? I thought we put the “Java is so stinkin’ slow” argument to bed back in the late 90’s early 2000’s.

All of the studies that I have been seeing show that the JVM with all of its optimizations and hot spot technologies have made it blazing fast. There have even been tests that have shown, in some cases, Java out performing its C++ counterpart. Now before you start flaming me, I am more than willing to admit that some of these tests could very well have been flawed or misinterpreted. I am in no way a “benchmark expert” and realize that it can be more of an art form than an exact science to do speed tests, but you can glean valuable information from the tests.

One college professor of mine loved one particular quote “You have lies, damn lies, and statistics.” This could very well be at play here, so short of me being a conspiracy theorist and spouting that some company that shall remain nameless (but starts with “Micro” and ends with “soft”), is behind the “sluggish Java” drivel, lets get down to brass tacks. Would industry experts and companies that specialize in high end scalability, such as Google and eBay, be writing systems in Java if it wasn’t fast?

This topic is just like any other, if you do not stay on top of the changing industry, you will be misinformed. Java, while in its infancy, was orders of magnitude slower than competing languages, but it just isn’t that way any more. I guess the moral of this story is to do a little research and question when you hear comments that don’t quite sound right. Of course that goes for statements that are for and against Java. Don’t swallow the blue pill, take the red one!

Share and Enjoy:
  • Digg
  • del.icio.us
  • Slashdot
  • Technorati
  • description

1 Comment for 'Lies or Statistics?'

  1.  
    February 23, 2008 | 11:57 am
     

    It really drives me crazy when I hear people complain about how slow or how fast this language or that language is: the real cost of the vast majority of computing endeavors is not in cpu cycles but in human resource costs. Let’s say for giggles that Perl runs 10% faster than Java. I can almost guarantee you that writing, debugging, and maintaining Perl code is a lot more expensive than doing the same in Java. The labor pool of skilled Java people is also larger than people who are equally good in Lisp.

    And if you are in the situation where you are at 99% cpu utilization and those 3 extra cycles are going to make a real difference, you are running your code on the wrong hardware. At that point you need to distribute your work across better servers. It is a simple fact that adding hardware to improve performance is cheaper than rewriting it in another language because Ada or Ruby or Pascal or whatever is too slow. (And yes, I acknowledge that crappy code will run slow no matter what kind of Cray supercomputer you run it on.)

    It’s really quite simple: Language choice should be viewed as an economic decision, not a technical one. When a technical strength or weakness of a language is brought up, the question should be “so what?” — which is inherently an economic assessment. Does 5% faster execution translate into noticeably better user satisfaction and retention, or lower costs, or increased sales, or anything else like that? And does it do so more cost-effectively than the alternatives, when everything else is taken into consideration?

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post | TrackBack URI