Slashdot Mirror


Java Profilers - Which One Are You Using?

splitPersonality asks: "Our Java programmers are researching various profilers to use in-house. We would appreciate some feedback from other shops that are using Java profilers. Along with the specific product, would you please include reasons behind your choice? If you now have misgivings about the one you or your shop chose, please let me know about those, as well."

13 of 79 comments (clear)

  1. YourKit: awesome profiler by jnana · · Score: 5, Informative
    I give my most enthusiastic recommendation to YourKit. It takes about a minute to install, has optional integration (1-click) with Eclipse, IDEA, Netbeans. I use Eclipse, and the integration there adds a new 'Profile as' options that works just like the 'run as' and 'debug as' launch options.

    YourKit is extremely easy to use thanks to a very intuitive interface.. All the java developers I've shown it to have been as impressed as I've been. It is cheaper than most profilers -- I got a deal on it for $125 a few months ago, which I is about 25% of the normal price, but it's still cheap at $499. It's not open-source, but they have a forum where they answer they questions extremely quickly. I've had 1 or 2 bugs since I've been using it (about 10 months), since I like to use the early release version for newer features, and both have been fixed within days, with a new build released within a week or so. Memory leaks are a snap to find using it's "compare snapshot", which lets you compare 2 snapshots and shows you what the difference is -- memory leak is generally the difference if you capture your snapshots intelligently.

    Anyway, I can't speak highly enough of the product. For the record, I have no affiliation with them at all. I'm just a very happy customer.

    My only minor gripe is that under some circumstances, the fastest CPU profiling option (unnoticeable impact on the running app) can give inaccurate results, in which case I have to use one of the two slower CPU profiling options, which are much, much slower--but that's certainly not particular to YourKit.

    1. Re:YourKit: awesome profiler by dubl-u · · Score: 2, Informative

      I give my most enthusiastic recommendation to YourKit.

      I second this. It's been a year or two since I looked, but I was happy to pay my own money for the YourKit profiler. In particular, I like the good UI. As with an IDE, I think it's worth paying for a good tool when it substantially increases my productivity, and the YourKit tool fits that.

  2. Profilers by overbarg · · Score: 2, Informative

    Java's available sets of tools for this kind of stuff is woefully inadequate, but here's what I use: NetBeans Profiler: Not bad for what it does, Memory Stack Allocation tracers are nice, but I haven't been able to get it to profile just certain methods in a selected class. It also seems pretty stable over long periods of time and doesn't interfere too much with the running of the application. JMP: I started using this for it's heapwalking abilities. Other things I've tried are hprof and hat... but with no success at all. JMP is not stable over long periods of time. It will frequently just decide to take a vacation even if you aren't monitoring anything, but for tracking down things like object owner chains, it's very good. Haven't done any actual performance profiling, so that's the extent of my knowledge.

  3. Re:Which one? Isn't it obvious... by Anonymous Coward · · Score: 4, Informative

    I use several tools depending on the application.

    For step-through-your-code debugging nothing beats Jprobe, although perhaps a fellow slashdotter
    can suggest a public domain equivalent

    If you want to profile your code in a "production" situation, i.e. you need minimal overhead
    while instrumenting methods to understand where in your stack trace time is being spent
    you have two options. Mercury Interactive sells a product that instruments all methods,
    aggregates method usage and gives you a "top talker" summary. Wyle Introscope on the other
    hand instruments only the methods you want, but can drill down into things like JDBC and capture
    executed SQL. Their product Leakhunter can help you find memory leaks, but creates too much drag for prod usage.

    Finally if want something that combines elements of Mercury's inclusive approach of instrumenting
    everything and top talker summaries and with Wyles approach of watching for heap usage, GCs and so
    on you want a copy of YourKit. I own all the products mentioned but have to say YourKit is my current favorite.

  4. OptmizeIt by SuperKendall · · Score: 2, Informative

    Although I've not had call to use one for a few years, I've liked OptimizeIt for a long time - they were bought by Borland but I think you can still buy the software on its own.

    JProbe also seemed pretty good...

    I also had good luck with HAT (heap allocataion tool, built into Java) if you are just looking for memory leaks. The HProf stuff also works and again is built in.

    ---> Kendall

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  5. JRat by Anonymous Coward · · Score: 5, Informative

    JRat is open-source, and works anywhere using bytecode injection. It's the only serious solution for profiling applications running in production as it

    A) doesn't require much overhead
    B) doesn't require code changes
    C) doesn't require some sort of front-end to monitor or use
    D) doesn't have a rediculous cost per server
    E) runs in your typical environment, not some magical profiling IDE option

    We use this every day (via an ant task) to profile a Wall Street trading system that handles billions of dollars of transactions every week. Would you trust that to anything else?

    Signing anon because my employment contract specifically prevents me from revealing this sort of thing :) Enjoy.

  6. JProfiler by Flwyd · · Score: 2, Informative

    We bought a few JProfiler licenses a few years ago and have had good success with it. It can easily profile remote JVMs (servlet containers, for instance). I've used the Heap Walker a few times to discover static references that shouldn't be kept around and have had good success finding performance bottlenecks.

    I hear recent versions plus 1.5 resolve a lot of stability and performance problems, but I haven't had enough problems to warrant pulling it out in a while. It's not a perfect product, but it's told us what we need to know.

    --
    Ceci n'est pas une signature.
  7. For us... by Leftmoon · · Score: 4, Informative

    We use DevPartner which seems to work pretty well for me. It's fairly neat the way it works. Although it does seem to identify some things as memory leaks that probably aren't actually leaks (ResultSets, IBM MQ Series objects, etc), if you limit the check to your own packages, a lot of your in-house errors will stand out right way and it will ignore the (assumed) false spots. Give it a try.

  8. Re:If you care about performance... by blafasel · · Score: 2, Informative

    it's actually very easy to get excellent performance out of java -- just use data structures as you would use them in C:

    • use arrays, not array lists etc.
    • avoid memory allocation
    • avoid side effects (and make judicious use of the final qualifier)
    • use public static methods (which the compiler is happy to inline)

    i'm currently using java to do classical molecular dynamics simulation (and statistical analyses thereof: esra), and the speed (without any tweaking) is consistenly within a factor of two of what i would get with C/C++. this is certainly not so with python (which, for my numerical problems, turned out to be about four orders of magnitude slower).

    YMMW, but mine is excellent ... no more segfaults, dead-simple deployment, scriptability, eclipse etc.

    --

    check your speling
  9. Re:If you care about performance... by Thunderbear · · Score: 2, Informative

    In a word no. (Except for aggresive inlining of code but I have not measured on that).

    "final" allow you to state information _in code_ about what you are doing about invariants, and letting the compiler enforce this.

    This allows the designer and maintainer to catch accidential assignments too. Not a bad thing.

    --

    --
    Thorbjørn Ravn Andersen "...and...Tubular Bells!"
  10. Re:If you care about performance... by espressojim · · Score: 3, Informative
    Often times it doesn't matter how much you profile your Java application. The bottleneck will often be hidden away, deep in some class library that either you can't modify (due to licensing restrictions or unavailable source code), or that you don't want to modify. Other times, the bottleneck will be in the inherently slow execution model of Java. Profile all you want, and change your algorithms all you want. Many times the only solution is to move away from Java in order to get the performance or scalability boost you may need.


    Last week I was profiling my code that connected to a database and retrieved data over and over. Originally, I'd bumped up the memory size on my VM to let the code run, because it was analysis code and didn't need to be super efficient until we moved it over to where the public could access it.

    The memory leak turned out to be in Oracle's jdbc driver. The TTCItem class was not being garbage collected, and a HUGE amount of memory (think everything sent over the wire from the database) was collecting. So, as you said, I had a bottle neck hidden away in a class library, and there was nothing I could do about it.

    Then I downloaded the latest oracle ojcbc14.jar, where I'd read on some forums that they'd patched the memory leak, and the problem went away. The problem was solved, the VM was running at 6M memory, and I was happy.

    If I hadn't had a profiling tool, I NEVER would have found that leak and fixed it. Who knew some versions of the oracle driver have a memory leak in their prepared statement handing? The solution isn't to walk away from Java, but to learn how to use the appropriate tools and programming techniques.
  11. Re:Memory leaks? What are you talking about? by splitPersonality · · Score: 2, Informative

    Few things not stated in my original post: While I do support the choice, I have no control over the language choice for in-house development. Having done large enterprise programming for many years and in many languages, it is my opinion that pure performance is rarely the sole reason a programming language is chosen. The decision usually considers the size of the talent pool, including in-house, available & reputable contractors, as well as job-seekers. Doesn't matter how good a language is if you can't easily hire programmers. I am not saying this is the sole consideration and definately not the primary one, but it is a big one. Others factors were open-source projects that could be used in conjunction with our developement, costs (IDE's and other tools), available quality education for existing staff, and a raft of others. Point is that the language choice is effected by the total cost of using it. We have also been sucessfully doing many smaller projects in java for several years. Fairly easy to track down any issues that come up. We are now laying the foundation for a massive multi-year project using contract programmers and new hires. We may not have any performance tuning issues early in the project, but what about in a year or two or five? Any experienced developer knows, you try to anticpate issues like that and lay the foundation for discovery and tuning BEFORE the coding starts. A profiling tool makes a lot of sense under these circumstances. One thing I learned a long time ago, doesn't matter how good and/or detailed the design process is, when the coding starts, stuff happens. The larger the team on the project, the higher the stuff factor. I don't know you or your professional background, so I may be merely reminding you of something you (should) already know.

    --
    "I don't suffer from insanity, I enjoy every minute of it." - author unknown
  12. JFluid by ungerware · · Score: 2, Informative

    JFluid (a.k.a the NetBeans Profiler)

    1. Free
    2. Trivial to configure/run (as easy as debugging in NB)
    3. You can specify a subset of the app to profile, and the rest of the app runs at full speed (profilers like JProbe force you to slow down the whole VM). This also makes the output much more readable, since you're not seeing all kinds of statistics from code you're not interested in.
    4. Attach/detach to a running application, which requires no special cmd line options when launching.
    5. Analysis tools are good at finding memory leaks, based on discerning patterns in allocation/deallocation

    Check it out at http://profiler.netbeans.org/

    --

    -----
    Kvetch is Yiddish for "throw an exception" --Dr. Ron Cytron