Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Eye on Java performance Improvements 84

Posted by michael from the tweak-tweak dept.
An anonymous reader writes "Performance. It's the one aspect of the Java platform that continually takes abuse. But the overwhelming success of the platform on other fronts makes performance issues worth serious investigation. In this article, Intrepid optimizers Jack Shirazi and Kirk Pepperdine, Director and CTO of JavaPerformanceTuning.com, look at compilation speed, exceptions, and heap size tuning."
This discussion has been archived. No new comments can be posted.

Eye on Java performance Improvements More

Eye on Java performance Improvements

Comments Filter:

  • "Level: Introductory" (Score:5, Informative)

    by jtheory ( 626492 ) on Friday August 01, 2003 @01:46PM (#6590457) Homepage Journal
    Level: Introductory
    Just a note -- don't bother reading if you've ever looked into Java tuning before.

    I admit I only skimmed the article... but the tips I saw are all simple suggestions that have been around for years now.

    Use Jikes for quick compilations? Jikes has been around since before the Java 1.2 days.

    Only throw Exceptions in "exceptional" cases, because they will slow things down? Again, advice I've been hearing since the early days.

    Nary a word about exploiting the new IO classes, or evaluating performance of XML vs. custom formats, etc. etc.
    • Introductory is even pushing it. I took one Java class, and I am by no means a Java expert and I found this article lacking. I hadn't heard any of these tips before, and then about the time I get into the article it ends.
    • Only throw Exceptions in "exceptional" cases, because they will slow things down?

      Actually, if you read the article carefully, you find that it says that you should only create exceptions in exceptional cases; that's the slow step, throwing and catching are fairly fast.

      So, presumably, if you create a single exception, and keep throwing and catching it, the performance would be much better. Of course the stack data will be wrong, since it will represent the place where it was created, but for many applicat

      • Yeah, yeah (Score:3, Interesting)

        by jtheory ( 626492 )
        I was summarizing quickly (yes, I know it's the creation that's costly) -- the point is that these are details about the language that any Java developer probably already knows or can intuit.

        I just wanted to warn off experienced developers who were expecting the "serious investigation" that was promised in the posting.

        By the way, I would NOT suggest reusing Exceptions. What you should strive to do is ensure that, in normal usage of your application, Exceptions will not be thrown (hence your program will
        • yes, I know it's the creation that's costly

          Frankly, I didn't. I knew that exceptions were expensive, but I didn't know why; and somewhat moronic summaries like yours (no offense, yours was about par for the course in fact) didn't help me understand why.

          By the way, I would NOT suggest reusing Exceptions.

          I would, where appropriate. I've just benchmarked it on jdk1.4.1 running Windows 2000, and I've found that exceptions run 20x faster if you do that (throwing an exception 1 million times took 10 seconds,

          • More comments (Score:5, Insightful)

            by jtheory ( 626492 ) on Friday August 01, 2003 @11:35PM (#6594060) Homepage Journal
            ...with less attitude (sorry, somehow I'm picking up the popular slashdot i-know-more-than-god tone... gotta watch that).

            The article in question does do a good job of explaining why Exception creation is expensive.

            I'm still dead-set against reuse of Exception objects, though, for some pretty good reasons. I've seen the suggestion before, and it bothers me because as optimizations go, it's very short-sighted.

            I'm sure you've heard the suggestion to "code for the human, not for the machine", because you code *will* need to be maintained, unless your project fails. ...and you may have also heard that this is nonsense and a great way to *ensure* that your project will fail because it's unuseable.

            As usual, the best answer is somewhere in-between. Every programmer should have the human reader in mind while designing and coding, but they should *also* design for efficiency. It has to be an informed compromise.

            Reusing Exceptions is one of those examples that I like to use of how *not* to optimize. It's a basic misuse of an integral part of the Java idiom. Everyone understands how Exceptions work, and how to use the stacktraces to find your error. It's dependable. The poor sucker who's on call when a customer calls because this application keeps crashing takes stacktraces for granted, and is going to be beating his head on his desk after 2 hours trying to figure out what is going on.

            This is a big cost. Okay, sometimes a cost is worth it, in optimizations. If this is a core data-crunching library that absolutely must perform at peak efficiency, maybe this is worth the painful maintenance cost.

            In this case, though, I can't think of any benefit to balance this cost, except that a programmer somewhere is pleased with herself for using an optimization she read in a book. If this data-crunching library is throwing Exceptions left and right in its normal processing, it's using Exceptions wrong.

            I hadn't thought about using the pre-made Exception hack to escape recursion -- it seems like a quicker way to get out than unwinding the recursion, after all -- but thinking about that more, I wouldn't suggest it even then. NOTE: comments below are not performance-tested, so if you really want to use recursion in a performance-critical part of an application, you should run some tests first.

            To begin with, recursion isn't a very efficient process in Java. Each time the method calls itself, all of the current local variables are stored, a new copy of the method is made (with new locals), and execution continues in the new copy.

            When you unwind the recursion, each of those stack frames and associated variables will need to be removed from the stack/heap and cleaned up, whether you exit normally or via an Exception.

            If you do exit via a reused Exception, you're misusing the functionality (as discussed above), and the benefits -- which will be slim, if any -- aren't worth it, because there are better options.

            If you're writing performance-critical code, you should use iteration, all in one method, instead of recursion, because it will perform better than even recursion with an Exception escape (probably in this case the cost is some readability.. recursion can be much more elegant).

            If it *isn't* performance-critical code, then you shouldn't be worried about unwinding the recursion. And I still don't like misusing basic Java concepts, but you could even throw a new Exception to escape w/o worrying about performance -- after all, 1 million new Exceptions in 10 seconds is still pretty darn fast when you're only talking about throwing one.

            -----
            Wow, I hope someone reads this... it was a lot of work to write out!
            • Reusing Exceptions is one of those examples that I like to use of how *not* to optimize. It's a basic misuse of an integral part of the Java idiom. Everyone understands how Exceptions work, and how to use the stacktraces to find your error. It's dependable. The poor sucker who's on call when a customer calls because this application keeps crashing takes stacktraces for granted, and is going to be beating his head on his desk after 2 hours trying to figure out what is going on.

              So what you are basically sa

              • I think we're actually arguing pretty close to the same thing here, for the important bits.

                But you must comment and document it very well because it is uncommon.

                This (in your words) is a big part of my main point -- if you're going to do something that might be hard for the reader to grasp, you should be aware of this cost.

                So what you are basically saying is 'nobody does it that way' so 'nobody ought to do it that way'?

                I wouldn't say "nobody should do it" -- I'm saying pretty much what you're saying
              • It's [recursion] exactly the same as any Java function call.

                True, but treating recursive calls in the same way as any other function is inefficient. Other languages (e.g. lisp) treat tail-recursive calls differently, removing the need to clear up the stack when the function terminates.

                • This can also be done for regular tail calls (not just for recursive calls) though it may be more work (depending on the underlying architecture).

            • There are cases involving callback mechanisms where throwing an Exception is the only appropriate way to stop some process that is not under the control of your own code. Say you're parsing an XML document, and you are only interested in the information in the header elements. An exception is a good way to stop a SAX parser from reading past the header information as it parses the file.
              If you had to scan the headers of many XML documents, it might even make sense to create a workhorse SAXException for this

            • To begin with, recursion isn't a very efficient process in Java. Each time the method calls itself, all of the current local variables are stored, a new copy of the method is made (with new locals), and execution continues in the new copy.

              A recursive call is just as fast as any other procedure call. You make it seem like a whole bunch of extra work is being done. "Storing" current local variables and making "a new copy of the method" often involves merely incrementing a register (the stack pointer)

              • A recursive call is just as fast as any other procedure call.

                True; I should have pointed that out.

                My point was that if we are talking about maximum optimization of an area of code, any construct that will call lots of methods in a tight loop isn't ideal, because of that overhead.

                Note: you'd only even consider this if you're trying to eek out every last drop of performance... don't screw up your code's maintainability for a gain that no one will notice.

          • (throwing an exception 1 million times took 10 seconds, reusing took 0.5 seconds on a 650 Mhz Intel- and frankly, a million is a heck of a lot of exceptions!)

            Mind you, if you've got code that throws a million exceptions in a day (I'd start worrying if it happened that often in a month), you've probably got a good reason to try to use some other error handling mechanism. Exceptions should be for when the shit hits the fan, not for dropping out of a loop where the programmer was too lazy to provide a no

            • It's never necessary to use exceptions; but it's nearly always a good idea.

              I figure when I'm being paid to do some work; it's more or less my job to do it the quick/short/lazy way rather than the long way (provided it doesn't do horrible things to the code maintenance or otherwise make the code unnecessarily brittle to changes.)

              Doing otherwise does nasty things to the profitability of the company- and I and the rest of the people I'm working with can end up out of a job.

      • bully Sun to add -Xnotrace option to disable stack trace in exceptions and make them efficient? Its nonsense to change class design because some feature that could be fast happens to be slow.

        Consider someone writting a low-level library that treats some condition (say, a math overflow) as an error and throws exception. Later someone else writes a program that generates a lot of overflows and handles them. Do you really want them to rewrite perfectly working code?
        • bully Sun to add -Xnotrace option to disable stack trace in exceptions and make them efficient?

          Nasty! So it throws an exception and you don't know where it came from; ever? YUCK .

          Its nonsense to change class design because some feature that could be fast happens to be slow.

          No, or yes, depending on what you mean here. The right thing to do is to create a new exception type that doesn't fill in the exceptions- for this kind of use.

          • Nasty! So it throws an exception and you don't know where it came from; ever?

            No, you turn off -Xnotrace and next time you see the complete call stack. Actually, C++ exceptions never record the call stack and it doesn't cause many problems. Why would you be opposed to the configuration option, turned on by the user of the application, when s\he is more interested in performance then debugging?
            • Because you turn it off for performance reasons, ship it, and get horrible information back from the field about what messed up IRL?

              Just because C++ did something one particular way, doesn't mean it's a good idea. In fact, quite the contrary in my experience.

    • Only throw Exceptions in "exceptional" cases, because they will slow things down? Again, advice I've been hearing since the early days.

      One tip from Java Performance Tuning [oreilly.com] by Jack Shirazi [javaperfor...tuning.com] is to create the Exception once, store it statically, and throw the object as many times as you need to.

      Ugly? Sure. Hacky? Definitely.

      But if you're after that extra bit of performance without leaving Java, need to use exceptions, and don't care about the stack trace, then it saves many cycles.

      One thing that I've found
      • One thing that I've found with hig performance numerical routines is the cost of array lookup (with all of its runtime range checking) is something that can really slow a routine down. I've taken a routine that ran in 500ms and tuned it down to about 80ms (running under the Hotspot compiler).

        I'm not totally surprised, but I am a little. Hotspot can often do range checking at compile time and remove the run time checks. However, for it to do that successfully may depend on subtle features of the code, so i

        • I'm not totally surprised, but I am a little. Hotspot can often do range checking at compile time and remove the run time checks. However, for it to do that successfully may depend on subtle features of the code, so it won't always succeed. Additionally it may well depend on which version of the jre you are working with.

          Range checking at compile time is probably best done by the javac compiler. Hotspot is busy compiling and converting java bytecodes at runtime, so it's unlikely it can do the complicated f
          • Actually I'm pretty sure the range checking is best done by Hotspot; the compiler doesn't get to see what calls what, Hotspot sees what functions get called by what other functions and is able to do a much better job of that kind of optimisation- it can even optimise into libraries, which the compiler never normally sees at all. Mind you, this is partly theoretical on my part, I best know about an experimental Sun language called Self which definitely works this way; but Self is what the Hotspot technology
            • There's a technical paper on HotSpot technology [sun.com] that covers much of the ground. It does mention range checking removal, but also some of the complications: dynamic loading of classes, runtime reflective method calling, and adherence to the Java security model. From a quick read it suggests that flow analysis is appropriate for inlining virtual method calls, and that de-optimization has to happen when the environment changes. Complicated stuff.

              I know enough about compilation optimization to appreciate how c

          • One problem with "javac" doing range checking may be that the JRE doesn't trust .class files. Everything is verified first. Unless it's easy to verify a correct bounds-check removal, the runtime compiler will have to duplicate the original analysis anyway. Maybe the bytecode could be extended to allow for compilation hints.

            Instead, "javac" could structure the output in such a way that it is trivial for the HotSpot compiler to figure out that the check can be eliminated. I believe HDL compilers do s

  • Optimize your way to ugly APIs (Score:5, Insightful)

    by brlewis ( 214632 ) on Friday August 01, 2003 @01:48PM (#6590468) Homepage

    They talk about how expensive it is to create an exception, and caution against it. Beware undue aversion to exceptions! For example, java.io.File.getLastModified(), if called on a file that doesn't exist, will return 0. An exception really ought to be thrown, but who's going to change the API now?

    People emphasize performance too much. Look how successful PHP has been despite its slowness. Deal with functionality first, and only worry about performance if and when it's a problem.

    • Deal with functionality first, and only worry about performance if and when it's a problem.

      But, then, how can we have flamewars about each J2EE vs. .NET report that comes out?!?!?

    • I agree to the extent that exceptions should rarely be ignored, unless that's somehow built into the functionality of your app. Teaching someone bad coding practices because of a limitation in the development platform is bad advice.

    • For example, java.io.File.getLastModified(), if called on a file that doesn't exist, will return 0. An exception really ought to be thrown, but who's going to change the API now?

      Oh, yeh that's right, because files not existing is really "exceptional" isn't it? This is an anoying wart for FileInputStream IMO, because now instead of doing all your relevant work in the call (Ie. does the file exist) you have to mix into all the real exceptional conditions like a NULL exception, out of memory, API errors l

  • Quick summary: Our software is good, thrashing is bad, and exceptions are still screwy.

  • Article doesn't say much (Score:5, Informative)

    by cxvx ( 525894 ) on Friday August 01, 2003 @01:57PM (#6590561) Homepage
    There are better articles on the IBM site discussing java performance:

    Knowing when to optimize is more important than knowing how to optimize [ibm.com]
    Urban performance legends [ibm.com]

  • Free Java Performance Tips (Score:4, Funny)

    by LarryRiedel ( 141315 ) on Friday August 01, 2003 @02:26PM (#6590855)

    • Try never to use java.lang.String.
    • Try not to use synchronized.
    • Try not to use java.io.* or java.net.* if there is something in java.nio.* that be used instead.
    • Try not to create objects.

    Larry

    • looks like you need to read this

      http://www-106.ibm.com/developerworks/java/libra ry /j-jtp04223.html

      • looks like you need to read this http://www-106.ibm.com/developerworks/java/library /j-jtp04223.html

        I do not so much think that excessive use of synchronization must have a significant performance impact as that it will have a negative performance impact. Nevertheless I do disagree with that article to the extent it suggests that synchronization and object creation/destruction do not significantly affect application performance.

        Larry

    • *Depends, when the data is suposed to be inmutable, you should use Stings (constants)
      If you are constructing your data, then a Stringbuffer is indeed best (In fact, Javac will try to use a Stringbuffer internaly)

      *Synchonisation is getting better with every release, now ofcourse you should not synch more than needed, but if you don't synch properly, you will find that deadlocks will be a far worse performance problem.

      *Yes, but sometimes it needs to be able to run on lower than 1.4 versions.
      Also, the NIO cl
    • * Try never to use java.lang.String.

      This is covered in the article. You're talking utter nonsense.

      * Try not to use synchronized.

      Yeah right. This is also covered in the article. Hey, have you read the article?

      * Try not to create objects.

      Guess not since that was also covered.

      Do you know how ridiculous that would be? An object oriented language where you don't create objects? Sure, you can make everything 'static', but what are you going to do about arrays, in Java they are objects

    • Try never to use java.lang.String
      One of the sins of my past was concatenating Strings together rather than using a StringBuffer. For example...

      String str = "foo"; str+="bar";

      rather than...

      StringBuffer str = new StringBuffer("foo"); str.append("bar");

      Mostly in building HTML in Servlets. I had not even thought about what was happening under the covers, and not thinking is what will bite you in the ass with any language. I was shocked to see how much faster StringBuffer concatenation was - but did not

  • java and net (Score:3, Informative)

    by raffe ( 28595 ) on Friday August 01, 2003 @02:28PM (#6590873) Journal
    Here [theserverside.com] is a recent study about java and .net.
    The result ?

    "The Middleware Company has released a J2EE and .NET Performance case study, the latest study (an MDA productivity study was released a few weeks ago) based on their Application Server Baseline Spec. Except for the web services test, the two platforms came out mostly equal in performance. "

  • Slow is relative (Score:3, Insightful)

    by bwt ( 68845 ) on Friday August 01, 2003 @02:32PM (#6590911)
    I always get amused when open source people spout of about how slow Java supposedly is and how much they love perl/python/php in the other. Java is pretty much faster than all of those. Yet nobody ever dogs on python (say) for being slow. Why?

    • I always get amused when open source people spout of about how slow Java supposedly is and how much they love perl/python/php in the other. Java is pretty much faster than all of those.

      There are different standards for "compiled languages" than there are for "interpreted languages." Plus you have to look at what the language is intended for. Java touts itself as an application language when perl/python/php are more of utility languages. Yes I know that you can do more than just simple parsing and cgi

    • Re:Slow is relative (Score:5, Interesting)

      by Dan Ost ( 415913 ) on Friday August 01, 2003 @03:22PM (#6591325)
      Why?

      Because if performance is an issue, you find your bottleneck and replace the
      bottleneck Python code with a C module.

      Suddenly your Python "Script" runs 99% as fast as if you'd written it in
      C in the first place.

      That's why nobody ever dogs on Python for being slow: Python makes it simple
      to get the performance you'd expect from C while only requiring a minimal
      amount of actual C code to be written.

      • Re:Slow is relative (Score:1, Informative)

        by Anonymous Coward
        *cough* JNI *cough*

        public native void slowInJava(...);
        Care to try again?

        • Re:Slow is relative (Score:3, Informative)

          by smallpaul ( 65919 )
          First, compare the ease of implementation to Python...especially when it comes to garbage collection and threading. Second, Python folks won't look down on you for using C where it is appropriate. Sun has this big marketing campaign about how code should be "100% Java". Third, Python people have worked much harder on tools to make integrating C easy: Pyrex, Distutils, SWIG, CTypes, win32com and pyxpcom.
          • So just because people look down on it, you refuse to use JNI?
            I will use JNI whenever I need to and if portability is possible, you need to provide a base fall through Java solution (for example if you want to do some hardcore number crunching, you make an extra version just in Java)

            I find JNI relatively easy to use when you need it

    • Re:Slow is relative (Score:2, Insightful)

      by Arandir ( 19206 )
      Python people aren't claiming that Python is greyhound of performance. But I have seen more than one article by a Java advocate making the strange claim that Java is faster than C.
      • But I have seen more than one article by a Java advocate making the strange claim that Java is faster than C. Well, maybe because it's a valid claim: in almost every case I've seen of fft implementations in java and c - java is faster (since 1.3.1). Thus, if you're only interested in that case java is actaully faster ;)

        yes, in the majority of cases c is faster - but not by a very wide margin (depending on the actual case of course) and then you have the occasional situation where the java vm is faster.
        • In some cases, yes, java is faster. And you named one of them: loop intensive math, where a runtime optimizer can do its best work.

          But to say C is not faster by a wide margin in most cases is ludicrous. It's precisely this attitude that caused this entire article to begin with. All the Java people say Java is fast, but keep wondering why it has an "unfair" reputation for sluggish performance. If Java is just as fast, then show me the Java office suite that was promised me ten years ago. I don't need one th
          • "Yeah, and because there are no successful office suits written in java that means java are slower than C/C++?"
            "So, can you show me any office suits written in assembly or machine code that are used successfully on todays computers, or do you mean that micro code is slower than C/C++?"
            "Have you stopped beating your wife?"
            Notice the similarity in the questions above? :)
            MUUUUU! (logic error)

            And yes, I still claim java not to be slower by a *wide margin* than C on most stuff that are programmed in an

  • Quick useful user-level approach (Score:3, Informative)

    by 0x0d0a ( 568518 ) on Friday August 01, 2003 @02:34PM (#6590940) Journal
    From a user's point of view, here's what's important WRT Java.

    * Java still uses a lot more memory and cycles than C/Pascal/C++/etc. Generally, if there's a Java program and a C equivalent, you want to use the C equivalent.

    * The IBM JDK is the fastest current way to run Java on Linux.

    * Eclipse is the free Java IDE that everyone loves.

    * No, the Freenet people still haven't made a C version.
    • * Java still uses a lot more memory and cycles than C/Pascal/C++/etc.

      Depending on what you mean by 'a lot more cycles' this may be either true or false. A well designed Java program is a percentage slower. Depending on whether you are spending longer waiting for the program to run or longer writing the program that tells you whether you should be writing in Java or C. But some things like floating point in Java can be as fast as C in some cases, so it's not clearcut.

      Generally, if there's a Java program a

    • Virtual machine type of controlled execution environments like Java or .NET have two advantages over C that will probably never be matched:

      1. Java and .NET can compile code optimized for your system on the fly. Got a nice P4-3.06 Ghz. Great, but most code is compiled for the lowest common denominator CPU so that it will run on all systems. Java's HotSpot can optimize the bytecode to compile to native code to take full advantage of your system.

      2. Java and .NET make it almost impossible to exploit a
    • Also let's not forget that you can write poorly written C (which isn't all that hard), and you can write beautiful Java, and the latter could be much faster and easier to maintain than your crap C program.
    • I'm going to disagree that the IBM JDK is the fastest. In my experience (enterprise server apps), the BEA JVM, JRockit, is the fastest. We ran some tests that showed something like the IBM 1.4.1 VM was 2/3 faster than the Sun 1.4.2 VM, but BEA 1.4.1 was more than twice as fast as Sun's. We watched the execution speed over time, and JRockit took very few iterations to reach top speed. Sun and IBM both took many more iterations. What's particularly nice about BEA is the builtin monitoring.
      • Its unfortunate that Sun's JVM is about the slowest one out there. Hotspot has never lived up to its potential. The poor performance of the reference implementation is one of the reasons Java has a reputation of being slow.

  • Memory Isssue (Score:1, Interesting)

    by Slick_Snake ( 693760 )
    At my work we have a program that is needed for information gathering. It was a custom job done by an outside agency. They chose Java as their language of choice. The program runs lots of processes and many threads. The average thread size is something like 52 MB. The total memory use of this program is something like 1.5 GB with about 500 MB of that resident in memory.
    Can anyone explain why java uses so much memory or is it just bad programming by the contractor we used.

  • I used to stress about Java performance. I'm not sure it was ever warranted. Certainly, things are plenty fast enough now.

    Not only have the JVMs improved - e.g. hotspot - but the servers and PCs I'm using now are 3 times faster (2.4Ghz vs. 800Mhz a few years back).

    What I think they need to concentrate on now, is getting the memory usage back down. 100MB to run an eclipse IDE is just too fat. And it's hard being a JSP Host [rimuhosting.com] when each Servlet engine chews up 60MB of memory on my host servers.

    FWIW, th

    • Eclipse will run in 4M of ram on my machine. I have to point this out every time Java is mentioned, and it's getting old.

      Try this:
      java -Xmx8M -cp startup.jar org.eclipse.core.launcher.Main

      That will limit Java's heap size to 8M. It will start and run just fine, but windows will say that you are using somewhere around 30-60M. Memory reporting under windows usually is flawed when it comes to Java. Java runs on embedded systems (I put a neural net on one once). I know it doesn't use that much RAM or CPU.
  • Performance. It's the one aspect of the Java platform that continually takes abuse.

    Oh no, there are plenty more after that... :o)

  • The Java/C++ flameware will burn eternally because there will be areses like myself that hear "Java" and think - "Those young punks like to overwrite they're array bounds. Thats going to cost them...Oh yes...that will cost them...Are they scared of my C pointers? I deal only in System V shared memory. I write my own hash tables. Of course your new fangled Java crap is slower than my code."

    I dunno...there can be enough hate between C and C++ that I don't think Java and C will ever walk hand in hand. Th

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close