Slashdot Mirror

I have used JMeter a couple of times to detect bottlenecks and synchronization problems with web apps. Very simple to set up and run just using a GUI. Apart from http/https it can appearently call java methods, EJBs etc too, but I haven't tried that. I think this tool is easier to use for stress testing rather than going through a whole use case. Also, when running against a web server of course it just tells you that something is slow, not what.

At Java One I talked to some fellow Swedes who were a bit disappointed with JProbe, they claimed it was a bit of a resource hog and that they had found a better more light weight open source library to use instead. I've looked through my notes, but it seems I didn't write down the name of the one they recommended. Darn.

Symantec had an app that seemed pretty impressive, though I don't know how much they charge for it. I think it was this one. I remember them because unlike most who just had a lottery for prizes, you actually had to run the demo to be able to answer their quiz. Pretty clever, made people remember and gave you a better chance of winning because most people wouldn't bother. I won a PSP. :-)

Also at Java One this year Sun had loads of labs and talks on profiling tools and frameworks that come with the JDK itself these days - JMX (especially in combination with DTrace if you run on Solaris), jconsole, jmap, jhat.

And then of course there is this whole site...

and how it relates to the volatile keyword (which I've rarely ever seen in Java code -- and if its not there, the code is NOT thread safe)

The volatile modifier requests the Java VM to always access the shared copy of the variable so the its most current value is always read. If two or more threads access a member variable, AND one or more threads might change that variable's value, AND ALL of the threads do not use synchronization (methods or blocks) to read and/or write the value, then that member variable must be declared volatile to ensure all threads see the changed value.

From the article:

And the garbage collection tweaking? They've hardcoded lots of values based on their tests "because for anybody to tweak them manually you would really have to understand the implementation of the garbage collector and what those things do". Everyone out there with production Java systems knows that what the engineers find optimal is almost never optimal in everyone else's systems, and we are grateful to have all those garbage collection parameters exposed in the JVM. Yes, it does require us to have a deeper understanding of what the garbage collector is doing, but that is the only way round, because the VM engineers cannot possibly have a deeper understand of the thousands and thousands of different applications out there. Those engineer-determined optimal values are still there of course, but as defaults in Java, not hard coded unchangeable options.

You don't know what "Just in Time" means, do you?
Here's an overview of it.

You can only reorder so much. If the order of execution depends upon data - for example, programs that accept data from the users, from a database, from chaotic systems, or from other programs, then you can't predict it at compile time. Of course, you may not believe this, but that doesn't make it any less true. Maybe one day you'll learn this.

As far as "a lot of CISC compilers," I can only assume that you're referring to gcc and Microsoft, because the other two players in optimization, IBM and Intel, have already moved way beyond that.

Notice this quote by one of the Hibernate developers in an interview earlier this year:

"I went into this knowing very little about ORM, and even very little about databases. One of my first tasks was to go out and buy a book to learn SQL properly. All my understanding of the problem comes from what our users have taught us over the last two years."

Sigh... basing a product on secondhand experience from users who probably have never even learned what the relational model is really about.

Great website for any Java programmer. Has helped me quite a bit.

But if you haven't heard of it http://www.javaperformancetuning.com/ is a good source of performance tips for java

I've coded projects in both Java and C++ (and benchmarked them, actually), and in my experience (which is just that) the C++ ran more quickly than Java. You're entitled to disagree. Where I work we use OptimizeIt which does help things out, but our software still runs absolutely dreadfully (I won't deny that likely much of it is the programming itself). But I still stand by my contention that C++ allows you to run faster than Java. It allows you greater control (directly) and doesn't impose any of the overhead of hierarchy that Java does.

I enjoy Java and program in Java and will confess that the stuff they include is usually useful (our software would probably be fscked if we didn't have GC or any of these other features, they just degrade performance (and I believe they have to). I would love to hear your response.

When I describe the mark and sweep method, it is the most common, and will likely be the most frequently used. However check here for an analysis of the other types. If garbage collection were a lightweight, trivial process, then why would Java need to implement 6 different schemes?

Incidentally, we tried testing the various different schemes here and it was a mess trying to get anything out of it.

Yeah, all you have to do is null the object and it'll be collected. Keep in mind, though, that in C++ you just do a delete (or a dealloc) and it's gone, you don't need to scan the whole environment doing reference counts and then doing the corresponding deallocs.

I agree that Java is fine, and it's sturdy, and it's a delight to use, it's just that (all the way up to the great-grandparent) I think that he got it right when Java programmers are (rightfully so) more concerned about all these optimizations (why do you think they're necessary?) than about any sort of run-time security.

Again, just my opinion.

Will this thing ever die?

Two years ago, (almost three), Java performance on Solaris wasn't very good. Why? Because it didn't need to be. As this article points out, Sun had better things to do two years ago than tune the JVM on a platform that it wasn't being used for.

If anything, this memo is an example of how things are working properly. Engineers complained, and things changed. If you look at some of the modern benchmarking linked from the provided site rather than ancient gossip, you'll see that the Solaris JVM is on par with the Windows JVM. Granted, they both need improvement in memory footprint and startup time, but the point still stands, the Solaris JVM is not lagging behind the Windows implementation.

Its time we put this one to bed.

-Zipwow

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 by Jack Shirazi 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 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). A comparable hand optimized assembler routine doing the same job took 20ms.

One example doesn't make a trend... but when you know what you're doing the performance is there for the taking.

Ian.