Build Your Own Java Performance Profiling Tool

An anonymous reader writes "IBM DeveloperWorks has an interesting look at creating a custom profiler using Java 5 and AOP. From the article: 'Profiling is a technique for measuring where software programs consume resources, including CPU time and memory. This article provides a list of best-of-breed features you might look for in an ideal profiler and explains why aspect-oriented techniques are well suited to achieving some of those features. It also introduces you to the JDK 5.0 agent interface and walks you through the steps of using it to build your own aspect-oriented profiler.'"

Comments

AspectJ

[El_Muerte_TDS]

Byte-code hacking!?
Why not simply use AspectJ?

Re:AspectJ

[ELProphet]

To say you did it yourself, duh!

The things he mentions are fun to do, and for some projects they may be necessary, but the big thing seems to be "My profiler is more customized than yours!" As for byte-code hacking and other "Refliective" programming techniques, that's the all-mighty Heavenly Father's (ar at least Matz's) gift to Ruby.

Re:AspectJ

[javaxman]

Byte-code hacking!? Why not simply use AspectJ?

You could as easily ask "Why use AspectJ", couldn't you?

I mean... what you're trying to do in the case of profiling is _not_ change the actual byte code you're working on any more than neccessary. Is using the aspectj runtime somehow better than using the -javaagent JVM option? I'm going to guess here... not neccessarilly, unless you're using AspectJ anyway. If you're _not_ using AspectJ and are not familiar with all of the extra syntax that AspectJ introduces, it becomes very unclear that doing your profiling that way is really a good way to go.

How would you specifically do the same thing they're talking about in the article using AspectJ ? I'm asking as a Java programmer who has shied away from using AspectJ ( the reasons for using it to me have not become terribly compelling; I'm aware that some folks love it ). Is there an article somewhere that spells out how to do the same sort of thing using AspectJ or some other AOP system? Maybe that would be a helpful link, or make another good story.

Re:AspectJ

[twiddlingbits]

DTRACE and Solaris. Too bad nothing like that exists for Linux and Windows.

Re:AspectJ

[DrEasy]

This probably won't compile, but just to give you an idea of how you could reproduce in AspectJ what the guy did in the article:

aspect ProfileAll {
    pointcut myMethod(): execution(* *(..)); //basically, affect all methods

    before(): myMethod() {
        System.out.println(thisJoinPointStaticPart.getSign ature() + "/tstart/t" + System.currentTimeMillis());  //print this before the execution of the method
    }
    after(): myMethod() {
        System.out.println(thisJoinPointStaticPart.getSign ature() + "/tend/t" + System.currentTimeMillis()); //print this after the execution of each method
    }
}

The above looks much simpler in my opinion, but maybe injecting bytecode somehow skews the profiling information less than doing so by injecting source code?

Re:AspectJ

[Trejkaz]

Correct me if I'm wrong, but doesn't AspectJ also use byte-code hacking?

Re:AspectJ

[Anonymous Coward]

You might find this interesting as well:

http://scholar.google.com/scholar?hl=en&lr=&q=cach e:i92bKFi5RZwJ:www.mcs.vuw.ac.nz/~djp/files/ECOOP0 5-SUBMITTED.pdf+profiling+with+aspectj

Its a paper looking at the strengths and weaknesses of using AspectJ for a number of classical profiling problems.

JVMPI

[iMaple]

I use the JVMPI by sun which IMHO does a pretty good job and is extremely easy to use. However the custom profiler looks easy enough and will probably be much more accurate. Worth a try for sure.

This annoys me greatly

[Anonymous Coward]

The only popular languages faster than Java are Assembly, C, C++, and Fortra. All of which take are enormously difficult to use for large scale projects.

Java's a speed demon compared to almost all other programming languages out there. So what if it's 1/5 (warning : 97% of statistics are made up on the spot...) the speed of Assembly?

Re:This annoys me greatly

[rubycodez]

there's plenty of other heavily used languages that have compilers that barf out machine code and that'll whoop your resource pig Java: LISP, COBOL, RPG/400, FORTH, and ADA to name a few.

Re:This annoys me greatly

[vectorian798]

While I do agree that for the most speed-intensive programs you need C, it isn't as bad as you seem to make it seem either. In many common algorithm tests, a JIT compiled Java program runs just as fast as its C equivalent. Also, the fact that Java is 'over 10 years old' is irrelevant, because C is over 30 years old. The fact remains that while a low-level is required for very intensive programs, in many applications the fastest program is not a necessity. This is often the case when you need to write a program where the database is a much larger bottleneck. Many companies use Java for speed-to-solution, and in this parameter Java easily outdoes C.

Also, your mention of DirectX having .NET wrappers is irrelevant. You can use DirectX with unmanaged code as well, it is just that it has wrappers available so that if you wanted to use it with C# or VB.NET, you can. It was NOT re-written in C# internally or anything like that, because that WOULD deliver a fair performance hit.

Anyways, I feel every programming language has its place somewhere. To say that one language is worse than another one in every aspect is more likely to be false than true since its an absolute statement.

Re:This annoys me greatly

[HotBBQ]

Either way, can you see anyone ever writing a library or API technology in JAVA

Yes and yes.

Re:This annoys me greatly

[Anonymous Coward]

I'm glad you have decided to stay out of my market. I'll make the money writing Java apps. You can keep feeding your monkeys. :)

Re:This annoys me greatly

[ultranova]

Either way, can you see anyone ever writing a library or API technology in JAVA, let alone an application that doesnt run like syrup on a cold day?

Yes. Batik, for example, is written in Java. Admittedly, it is much slower than Inkview in starting up and opening a file, or opening another file once started, but on the other hand, it supports filters (which inkview doesn't) and clips properly at image edge (inkview doesn't), and supports scripts and other niceties.

JAVA is over 10years old, and yet on P4 3.4ghz computers, you have to performance optimize even simple appliations to run reasonably well. Who in the heck thinks this is normal?

X86 assembly has been around since 1978, and even on a P4 3.5GHz computer you have to optimize to run well. I guess that means that assembly equals bad performance. It couldn't possibly be because "simple application" nowadays means something different than 10 years ago.

Not to say that Java is neccessarily a fast language, but saying that "you have to optimize to get good performance" is true for any programming language.

Re:This annoys me greatly

[Anonymous Coward]

it's fine, learn to code.

Re:This annoys me greatly

[Anonymous Coward]

In many common algorithm tests, a JIT compiled Java program runs just as fast as its C equivalent.

I keep on hearing this, but I've never seen it. Got any links to things that aren't something stupid like for (int i = 0; i < 100000; i++) { }? The only examples I've ever seen of a JIT compiled Java program being able to come anywhere close to a C program are the most stupid and contrived examples. (And, when you actually compare them, you'll note that the C program did it in the same time, using 32KB, while the Java program did it using a meager 10MB.)

I've played around with everyone's favorite "Java doesn't have to suck" example, Eclipse, and - it sucks! It's slower than native apps, it suffers the same random freezes people blame on Swing, and it's a giant resource hog.

I've never seen a Java program come anywhere close to a C program. Do you have any actual links?

Re:This annoys me greatly

[Doc_NH]

I've played around with everyone's favorite "Java doesn't have to suck" example, Eclipse, and - it sucks! It's slower than native apps, it suffers the same random freezes people blame on Swing, and it's a giant resource hog.

That is amazing since it it is build SWT, but I am sure that in your opinion the the pure suck value of swing being in the JRE would slow eclipse down.

Re:This annoys me greatly

[hunterkll]

This was a funny, not a troll.... Who uses such ANCIENT and USELESS languages anyway! :D

Re:This annoys me greatly

[rubycodez]

your bank and credit card company

Re:This annoys me greatly

[ari_j]

The Orbitz backend makes extensive use of Lisp.

Re:This annoys me greatly

[TheNetAvenger]

You can use DirectX with unmanaged code as well, it is just that it has wrappers available so that if you wanted to use it with C# or VB.NET, you can. It was NOT re-written in C# internally or anything like that, because that WOULD deliver a fair performance hit.

No, not all of it was rewritten in managed code, but there are performance level areas that were moved to managed code for stability and security.

Go check out channel9, and see the DirectX team talk about the decision to move parts to managed .NET code (which does not mean it was written in C#, .NET is language independant, even creating managed code).

They talk about the security and stability reasons and the concerns for the performance trade off by moving to managed .NET code.

The were happy to realize that performance was not a significant issue.

Please don't take my word for this, or anyone else's go look this information up yourself...

Re:This annoys me greatly

[TheNetAvenger]

Yes and yes.

I will buy its viability after another 10 years of hype, and when they can show the industry companies like ATI or NVidia using JAVA for video driver library performance level coding.

They already use .NET managed code in parts of their drivers on Windows, I don't see JAVA performing that role or hitting that level of performance.

I could be wrong, but I was an early JAVA lover, and even stuck with them when they cut of their nose to spite their face with the MS lawsuit, but to date Sun has not provided what JAVA was promised to be back in 1995, not EVEN close. I am tired of waiting on them, when other technologies are emerging with the same 'cool' factors and are already more mature.

In a way I hope I am wrong, but I don't ever see JAVA being credible, they lost their window.

Re:This annoys me greatly

[TheNetAvenger]

X86 assembly has been around since 1978, and even on a P4 3.5GHz computer you have to optimize to run well. I guess that means that assembly equals bad performance. It couldn't possibly be because "simple application" nowadays means something different than 10 years ago

You even know this is a bad excuse...

Optimization is always something EVERY developer should be doing. However, there is no way to 'override' some of the inherent performance issues present in JAVA currently.

And no it has nothing to do with simple applications. I can write an XAML .NET application doing 3D animations on a non GPU accelerated computer, and write a few lines of code very quickly, and present a fully functionaly appliation with stunning visual effects and abilities current desktop software marvels at, and sadly it performs better than JAVA by a factor of 5, and this is beta software and development tools and beta technologies, but are already more mature.

Sad....

Re:This annoys me greatly

[Anonymous Coward]

but to date Sun has not provided what JAVA was promised to be back in 1995

Correct me if I'm wrong but I recall a promise about an environment where I could program in Linux and run on Windows. I'm but a Java beginner but still think that I'm in my place to say that if you can't get this promise working you really have to put the blame somewhere else.

As for the games (I knew it, thats what bothered you; you didn't find the cool games to play!) just look a Java Website

Sorry but this response is IMO silly. It only describes your failing of not being open to the way in which Java was heading. You could see the Java bus drive into another lane, honking its horns and flashing it lights yet you stay at your same station waiting for it to arrive.

Now a whole new station has been build before you and you can once again see the big bad Java bus drive in and here you are again just waiting for the thing to change itself to your expectations, not even noticing that it has already surpased a lot of those promises a long time ago.

Re:This annoys me greatly

[TheNetAvenger]

Correct me if I'm wrong but I recall a promise about an environment where I could program in Linux and run on Windows. I'm but a Java beginner but still think that I'm in my place to say that if you can't get this promise working you really have to put the blame somewhere else

You are a beginner... Internet applications to Internet distributed platform independant applications, including business applications.

Go reseach where Corel tried to put a lot of work into pulling off some interesting JAVA based application work. They even wanted to create WordPerfect in JAVA. Even what features they could recreate failed horribly, and Corel told Sun to go pound sand.

Ya you can program in JAVA and they will run on Windows or Linux, you can also program in Pascal and create a version for Windows and Linux that runs at the OSes native speed.

JAVA tries to be, and continues to try and be an OS development sandbox on top of an OS. The thing is JAVA isn't 'good' enough to be a simple OS, let alone one that runs efficiently on various OSes.

JAVA should abstract the OS tools and libraries and sandbox that, instead of recreating the wheel. As you watch the coming years where new application technologies become the standard, projects using OpenGL full time for a 3D desktop on Linux to Vista and its massive use of GPU and 3D application accessibility to simple five line code applications.

What is going to happent to JAVA? Are they going to 'reinvent' the JAVA display technologies for every OS incarnation because they chose to write their own in the first place? Here is where it gets tough, if JAVA did crossplatform right,it would set a common feature and standard set (as they have done) but it would translate through the existing OS to utilize the features of the OS, instead of recreating their 'standard' across OSes.

For example, take advantage of the Windows Display technologies, controls, etc as much as they can so that it don't break the JAVA standard, do the same with OSX, Linux, Solaris, etc.

Then you would have the chance of creating a Development platform running at a respectible speed across OSes.

Some people really don't get this one simple concept. JAVA is not even technically a high level 'development language', it is an 'application that provides development features.' In other words, when you are running a JAVA application, it is your application running on the JAVA application environment. So you are basically turning over your appliation to an Application pretending to be an OS technology running on top of another OS.

So since JAVA is about as open as a bank safe, what happens when they change the rules of the game on you, give up on it?

With other languages, you could recompile, and port for a new OS, with JAVA you can't, your application is dead...

Re:This annoys me greatly

[Anonymous Coward]

As you watch the coming years where new application technologies become the standard, projects using OpenGL full time for a 3D desktop on Linux to Vista and its massive use of GPU and 3D application accessibility to simple five line code applications.
What is going to happent to JAVA?
The current 'blank box' approach won't stop them from, for example, implement specific classes which deal with these OS specific manners. Just like the comm package which is different for Unix, Linux, Windows and which you can use to deal with serial communications.

So since JAVA is about as open as a bank safe, what happens when they change the rules of the game on you, give up on it?
Dunno where you have been hanging out but I have the full Java sourcecode, freely downloadable from Sun, which allows me to see all it is about. I'd call that pretty well opened up.

With other languages, you could recompile, and port for a new OS, with JAVA you can't, your application is dead...
I don't think so. Why do you think Sun is pushing so hard to implement a "Linux container" to virtually run Linux applications, or why BSD ships with "Linux compatibility libraries" and the likes? In most cases you can't simply "recompile for another OS", you'd have to restructure the entire program.

If you're optimizing Java, you're sunk

[Anonymous Coward]

If you're to the level where you're profiling code, you shouldn't be using Java, period. If you're at the point where you're trying to optimize Java code, you should be using native code.

But, if you want to know better alternatives to Java, there's always Python, Ruby, C#, or a host of other languages that don't have the massive memory problems or library bloat that Java has.

Re:If you're optimizing Java, you're sunk

[Anonymous Coward]

Ruby and Python are so much slower than Java that it's retarded to suggest those two when the discussion is about achieving better performance.

Re:If you're optimizing Java, you're sunk

[HotBBQ]

That's simply not true. I work on a large Java project that deals with a lot of matrix intensive work. Our Java code has been rigorously architected, engineered, and optimized. The matrix code in particular (where the majority of our processing time is spent) is far superior in Java than it was in C or C++. Every programming language has its place, use the one that suites your needs. Profiling most any code can reveal useful information.

Re:If you're optimizing Java, you're sunk

[andrewwilcox]

You're implying that there are languages (other than Java) that don't ever require profiling which is simply rediculous.

Re:If you're optimizing Java, you're sunk

[throx]

The matrix code in particular (where the majority of our processing time is spent) is far superior in Java than it was in C or C++.
If your code is targetted to a specific platform then all that says is your C/C++ coders were idiots. The only case where a jitted language exceeds a natively compiled language is where the JIT compiler can apply optimizations the native code compiler cannot for compatibility reasons (eg avoiding SSE3 when you might run on an older CPU).

There is no excuse for heavy math code such as matrix processing to be faster in Java than C/C++. In the absolute worst case, you can simply take the machine code generated from the Java JIT and reproduce better code in C/C++.

Re:If you're optimizing Java, you're sunk

[animaal]

The only case where a jitted language exceeds a natively compiled language is...

Actually, the post to which you replied never said the Java solution was faster than a C++ implementation. He said it was "superior". True, it is a vague term, but for his organization, superior may mean "easier to maintain", "smaller codebase", "easier to use on other hardware platforms", or any other number of possibilities.

Re:If you're optimizing Java, you're sunk

[HotBBQ]

Sorry , but no. The matrix library we use was written in C++. We used a Sun Blade 1000 system (SSE free) and the Sun compiler to run an extensive set of sample calculations. The code was ported in house to Java 1.5, making only minimal changes to make it Java compatible. The same sample calculations were performed using the Java library and were approximately 15% faster. We initially thought we had done something wrong, because we all assumed the C++ code would be faster. We verified, verfied again, and verified some more. A few changes were made but the Java code just got faster. Believe what you will, but in this case the Java was faster, and we had the metrics to prove it.

Re:If you're optimizing Java, you're sunk

[Doc_NH]

Ever heard of HotSpot? Java JVM does runtime optimization that C/C++ can't. No it doesn't happen in a two second bench test designed for C to prevail, but use in real life applications the JVM performance improves with longer runs. If you honestly look into it and realize that your "java is slow" mantra is a bit dated or is that a SlashDot fact that is not refutable?

Re:If you're optimizing Java, you're sunk

[NialScorva]

What matrix library were you using for C++? Was it hand-rolled, and if so was it faster than C++ matrix libraries like Blitz++?

Re:If you're optimizing Java, you're sunk

[Anonymous Coward]

But, if you want to know better alternatives to Java, there's always Python, Ruby, C#, or a host of other languages that don't have the massive memory problems or library bloat that Java has.

HahAhhaHAHAHahAhAhA "Python", "Ruby", they are primitive if compared to JVM. BTW, how old are you? 13?

Re:If you're optimizing Java, you're sunk

[HotBBQ]

I forget the name of the C++ library and it's past 5 o'clock here so everyone has left. We have moved on to the Colt http://dsd.lbl.gov/~hoschek/colt/index.html matrix library.

Re:If you're optimizing Java, you're sunk

[angel'o'sphere]

There is no excuse for heavy math code such as matrix processing to be faster in Java than C/C++. In the absolute worst case, you can simply take the machine code generated from the Java JIT and reproduce better code in C/C++.


Following your logic I rather would write: There is no excuse for heavy math code such as matrix processing to be faster in C/C++ than in Java. In the absolute worst case, you can simply take the machine code generated from the C/C++ compiler and reproduce better code with the Java JIT.

Bottom line: you have to admit that there is an "optimal" code for doing a certain matrix problem (general matrix is different from a diagonal one e.g.). It does absolutely not matter if that optimal code is generated by a C++ compiler or by a Java Jit.

For general purpose computing Java is as fast as C++, since 4 to 5 years. Even Doom clones and 3D engines are written in Java in our days .... get a clue, go with the time, stop repeating over half a decade old mythes.

angel'o'sphere

Re:If you're optimizing Java, you're sunk

[cecom]

Sorry, but you are wrong. For some things Java can never be as fast as C/C++ due to the definition of the language itself - things like lack of value objects, specifics of method dispatching, late binding, etc.

I don't want to go into details here, but as a good example of Java's inefficiencies think about an array of complex numbers in Java and C/C++. Java is at least an order of magnitude slower in this particular example and no JIT can ever fix that unless the language itself is changed. If you don't believe me and you know C and Java you can even try it - write a small program performing a simple operation with the array - for example sum of the elements.

Admittedly matrix algorithms do not necessarily exhibit the problems I am talking about. However I sincerely doubt that the current generation of JAVA JITs do complex optimizations like loop reshaping, cache blocking, prefetching, etc.

Re:If you're optimizing Java, you're sunk

[Jekler]

You are grossly misinformed about the inefficiencies of Java. It is extremely easy to examine two languages and design a 20-line test that shows that one is faster than the other.

This does not make Java "an order of magnitude slower...", a real test of requires two seperate developers, with roughly equal skill in their respective languages, given a general problem and the task of implementing a solution, then comparing the resulting applications.

Given those results, the first thing you'll note is that all the specific instances you previously cooked up (your "Fool's loop test") which proves Java is slower doesn't matter, because the Java-equivilant solution to an actual problem is entirely different. Everything about the structure of the code, where and when messages are sent, right down to the type and size of objects will be entirely different between languages.

Your test uses the assumption that in order to test Java's execution speed, the only necessary step is to take a program in C++ and translate the code, line for line, into Java syntax. The difference between programming languages is not in the syntax.

Your test is like redoing a physical structure by, beam for beam, replacing it with a different material. As any architect can tell you, the placement of the load-bearing beams will need to be dramatically altered depending on the material you use. If you take the design for a timber home and instead use concrete, the whole thing will cave in. Does this mean that concrete is weaker than timber? But yet, if you take a timber plank and slam it into a concrete wall it'll splinter into pieces. Wow, what a bizarre phenomenon!! It's as if, under different circumstances, each material has varying levels of suitability.

Your test is as ridiculous as arbitrarily declaring a search engine superior based on the results of a single keyword. "I'll prove Yahoo is the best! If you search for 'chicken', Yahoo returns better results! Therefore Yahoo is superior to Google!"

Re:If you're optimizing Java, you're sunk

[throx]

Following your logic I rather would write: There is no excuse for heavy math code such as matrix processing to be faster in C/C++ than in Java. In the absolute worst case, you can simply take the machine code generated from the C/C++ compiler and reproduce better code with the Java JIT.
No, you can't. The language restrictions of Java are far more significant than the language restrictions in C. For example, you cannot perform unchecked array access in Java on arbitrary memory. In a very real sense, Java's performance on a given platform has an upper bound at C's performance.

Bottom line: you have to admit that there is an "optimal" code for doing a certain matrix problem (general matrix is different from a diagonal one e.g.). It does absolutely not matter if that optimal code is generated by a C++ compiler or by a Java Jit.
There is definitely optimal code, and I am saying that that code will not be able to be produced by a Java JIT compiler because the structure of the java language is unable to deal with it as efficiently as the structure (or absence of structure) that the C language has.

The Java code will probably be more maintainable and less error-prone, but to suggest that it will outperform optimized C code is patently ridiculous.

For general purpose computing Java is as fast as C++, since 4 to 5 years. Even Doom clones and 3D engines are written in Java in our days .... get a clue, go with the time, stop repeating over half a decade old mythes.
Java is not as fast as C/C++. It's simply a function of the language. In optimized cases, the speed difference may not be great but Java does have performance penalties defined by the language (garbage collection, checked array access, etc.) that are simply not present in C. You might write a Doom clone, but you sure won't write a F.E.A.R. clone. Take your binders off and realize that the tradeoff for the manageability and elegance of Java is some speed. It's no myth - it's a raw fact.

However, if you still choose to disbelieve me, please post the Java source code you believe will outperform optimized C/C++ code. I'd be fascinated to test it out.

Re:If you're optimizing Java, you're sunk

[cecom]

I shouldn't really be replying, since you already said that all the specific instances which prove Java is slower don't matter - how could I argue with that ? However I would like to benefit from your obvious knowledge of the matter.

Also, please note that I didn't say "C/C++ is best", which you seem to be implying in your last paragraph - I was commenting in the context of the thread about Java vs C/C++ performance for matrix computations. I don't care about language wars, because obviously everyone who disagrees with me is wrong ... :-)

I have seen many claims about Java's performance, ranging from reasonable to absurd and ridiculous. For example:

• Java is as fast or faster than C for everything
• Java is as fast or faster than C for everything that Java is normally used for
• Java is slower but fast enough for most things
• Java's performance doesn't matter because everything is IO and network bound anyway
• etc

I would love to share my opinion on these subjects some other time, but for this post they are irrelevant.

So, getting back to the subject. Obviously you agree that for the scenario I am describing, Java is slower than C. You contend that this results from "translating line by line from C into Java syntax". OK, enlighten me then. What is the Java-specific solution for keeping complex numbers in an array ? You can go wild - use any Java tool and technology. This is not an artifical scenario. The same problem exists for arrays of 2D or 3D coordinates, actually arrays of anything except primitive types, so if you present a solution I will be very grateful and even offer to buy you a beer ot two (or a dozen!).

Re:If you're optimizing Java, you're sunk

[michaelm001]

Ahh...your typical uninformed slashdot poster...

You do realize that array bounds checking is eliminated by modern VM's? i.e. HotSpot. Suggest you read:

http://java.sun.com/products/hotspot/docs/whitepap er/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4 .html

The Java version of Quake performs faster than the C version:

http://www.bytonic.de/html/benchmarks.html

Here are some other benchmarks:

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html
http://kano.net/javabench/

Java VM's such as HotSpot have the ability to de-optimize and re-optimize on the fly. C/C++ can not do that.

Stop repeating the lie that Java is slower than C/C++.

Re:If you're optimizing Java, you're sunk

[Anonymous Coward]

If you are really so ignorant as to think benchmarking "a small program performing a simple operation with [an] array" means anything at all about the overall runtime efficiency of 99.99% of the applications in each language written or about the respective language implementations in general, you are truly a hopeless fool, and there is no point in discussing anything.

I'm sure now you'll backtrack, blah blah blah, but only a moron would say such a thing. And for the record, Java is far from my favorite language.

Re:If you're optimizing Java, you're sunk

[angel'o'sphere]

However I sincerely doubt that the current generation of JAVA JITs do complex optimizations like loop reshaping, cache blocking, prefetching, etc.

But you are wrong.
And your example about complext numbers ... you fail to explain why C++ should be faster ... you likely won't use value objects for most operations in C++ but use references ...
You won't need virtual methods in both cases, so you use standard methods (or non virtual operators).
Especially in vector math and matrix operatiosn Java is proofen to be as fast as C++, except for hyper specialized template libraries like Boost, which have factored out special situations into templates.

angel'o'sphere

Re:If you're optimizing Java, you're sunk

[angel'o'sphere]

The Java code will probably be more maintainable and less error-prone, but to suggest that it will outperform optimized C code is patently ridiculous.


Well, you are to narrow minded. Your example about arrays is strictly correct, but modern Java jits REMOVE the array bounds check if they can prove that the index will never be out of bounds. So this arguemnt does not hold ... most of your other arguments are to narrow minded as well.

So I only picked the one above.

Please: why the heck do you think that a linked list traversal in Java MUST be slower than "optimized" C code? Whatever "optimized" in that context may mean?

Just because Java has an "not null" check?

Sorry, but sentences like this: because the structure of the java language is unable to deal with it as efficiently as the structure are complete nonsense. Java has only a few runtime checks. Those take not much time. Often during Jit compiling and Hot Spot optimization those checks can get removed, and are removed. At that stage the code is as efficient as C.

Your whole argument chain is not taking into account modern compiler technologies. In fact languages like Haskell or Occaml or Self or Erlang have prooven that OO and functional languages can be transformed to more efficient code than C. C is just transformed "structure" by "structure" into assembelr and is then fix.

Modern compilers do much more controll flow and data analysises and inline much more. The above languages do that mainly even static at compile time, and Self and Java during Hot Spot analysis at runtime. They basicly try to attempt what template metaprogramming does for C++, and they succeede in that (google ... there is lots of research, even old research about that)

angel'o'sphere

Re:If you're optimizing Java, you're sunk

[owlstead]

If you like performance, try the 1.6 VM (beta)! Although it should make much more of a difference on a Windows box really. The code speedup that I got was about 50% for a heavily algorithmic application (cryptographic, mostly SHA-1, unoptimized). I presume it has to do with the better register handling of the VM. This is one of the fun things about Java, it can get faster without recompilation of any source code.

Re:If you're optimizing Java, you're sunk

[cecom]

Am I really wrong about complex optimizations like cache blocking and prefetching ? I might be - however unless you provide a verifiable reference I am disinclined to believe you. Many static compilers don't even do those.

To answer your question about why C++ would be faster. Examine the C++ declarations below and think about how fast a sum of the entire array would be in each case. If you like to look at the bigger picture, think about memory consumption too.

double arr1[10000];
double * arr2[10000];

Re:If you're optimizing Java, you're sunk

[throx]

I'm not narrow minded, I'm just not a Java bigot like you. The simple fact is you can optimze C code more than you can optimze Java code. All the studies (which I have looked at extensively) show that generic C code can be outperformed by Java but they neglect the fact that the C code can also undergo optimizations. The typical assumption is that gcc is the compiler, which immediately puts the C code at a significant disadvantage. Get a real compiler which allows hinting on aliasing and other things that the Java JIT uses.

Looking at your ridiculous claims:

Java jits REMOVE the array bounds check if they can prove that the index will never be out of bounds

In short, Java *can* be as fast as C if the compiler can prove to itself that the array doesn't go out of bounds. If it can't, then it's slower. My statement remains - the upper bound of Java is optimized C.

why the heck do you think that a linked list traversal in Java MUST be slower than "optimized" C code?

I don't - you're just a failure at english comprehension. I said its upper bound is optimized C performance (where optimized means what the dictionary says it does - that you've made it as efficient as the language allows). This means that it is either slower or equal. I'm even allowing Java the advantage of ignoring JIT time there.

Java has only a few runtime checks. Those take not much time. Often during Jit compiling and Hot Spot optimization those checks can get removed, and are removed. At that stage the code is as efficient as C.

So, my statement is correct. The performance of Java has an upper bound at the performance of C, in the case where all the runtime checks are removed. In the case where they aren't (which you admit is possible) then Java is slower. You see - you're losing your own argument.

Your whole argument chain is not taking into account modern compiler technologies.

Garbage. Your argument is not taking into account modern C compiler technologies, which use everything that Java has available. The fact that I'm comparing optimized C code eliminates any advantage Java has in runtime analysis because optimizing C involves runtime analysis and recoding to suit.

In short, you're the narrow minded bigot here. I'm just stating facts that C allows the programmer much more freedom to optimize the code manually with knowledge that is not able to be represented to a Java JIT compiler.

However, please feel free to continue defeating your own argument with proofs that Java can equal C's optimized performance if the JIT can recognize the conditions as right.

Re:If you're optimizing Java, you're sunk

[throx]

Ahh...your typical uninformed slashdot poster...

Not guilty. However, you seem guilty of Java bigotry and failure to read and understand research papers.

You do realize that array bounds checking is eliminated by modern VM's?

Of course, and I've read the paper you linked. Thanks for telling me stuff I know and even recognized in my previous posts by saying that Java has an upper bound at C's optimized performance. *If* the runtime checks can be removed then Java array access is as fast as C. If they can't then Java is slower.

The Java version of Quake performs faster than the C version

The C version was compiled for a 386. Recompile it and optimize it and you'll get a hell of a lot more performance than the original. Do you really think that game developers are all idiots for using C/C++ for their game engines instead of Java? Here's a big smack with the cluestick for you - they use C/C++ because it offers better performance when optimized. When I see a game released under Java then I might give you some credibility but until then you're just another tired old bigot comparing a modern JIT with a C program compiled for a 10 year old processor.

Your other benchmarks are just as telling - they compare Java code with unoptimized C code using the worst possible compiler for performance (gcc). You do realize modern C optimization allows the developer to specify pointer aliasing, efficiently use registers and processor features through intrinsics and other optimizations that the JIT uses in the cases that you demonstrate performance advantages over C/C++ code.

Simply put, the only cases where you demonstrate Java advantages are in comparisons to unoptimized C. If all you have is comparisons using C as a baseline rather than comparisons with optimized C then you're deluding yourself and pitching out the lie that Java *is* as fast as C rather than the truth that Java has an upper bound at optimized C's performance.

Java and Hotspots optimize on the fly. C coders optimize better through runtime analysis and knowing meta-information about the code that a compiler can never hope to know.

Re:If you're optimizing Java, you're sunk

[angel'o'sphere]

Oh, I see now what your point of arguemntatin is:

you always speak about the upper bound is optimzed C. So you want to say: Java is most of the time slower than C, and in the cases where it is approaching C speed, it is at max on equal speed.

Sorry, I have to admit I missed that little word uper bound. In fact it is not nice of you to make a conversation over 3 posts and finally hit me with that into my face.

So let me give you a last small example:

Your argument is not taking into account modern C compiler technologies, which use everything that Java has available.


Thats wrong.

C is compiled staticaly before the code runs. Most (not all) C compilers only look at the compilation unit and don't take stuff into account from other compilation units. A very simple situation where the C model fails is: compile a program to Pentium code and let it run on a Pentium 4. It does not "adapt" to the new processor as it is staticaly compiled. All static compileds languages fail there and all have the same fix: recompile. But still then the limited scope of only one compilation unit stays.

Java looks at Jit time on the whole area of interest. And that includes method calls spanning several compialtion units. C in general does not do that. So C in general is not upper bound the limit of what Java can do.

As I mentioned before .... google is your friend. There are at least 100 research papers about exat this topic. Ppl are no longer interested in "optimizing" C compilers, its boring. People research other languages and other problems, e.g. optimizing code generation for OO systems on multi processor (or multy core) hardware.

There are hundrets of probelms you can't even express in C but only model around by using libraries (like synchronization). How you can think that C is always on the same speed if not faster if it goes into optimizing stuff you can't even describe is beyond my imagination.

angel'o'sphere

Re:If you're optimizing Java, you're sunk

[michaelm001]

Java and Hotspots optimize on the fly. C coders optimize better through runtime analysis and knowing meta-information about the code that a compiler can never hope to know.

What do you think hotspot does??? It does runtime analysis. You can even set the compile threshhold...i.e. execute 1000 times before compilation, or wait longer for a better compile.

See this:

".... Also, profile data is collected by the interpreter for guiding the optimizations."

here:

http://java.sun.com/developer/community/chat/JavaL ive/2005/jl0315.html

So it DOES do runtime analysis optimization. C code can only be optimized for certain scenarios, whereas hotspot adapts and will de-compile and re-compile as the state of the program changes.

Re:If you're optimizing Java, you're sunk

[throx]

Sorry, I have to admit I missed that little word uper bound. In fact it is not nice of you to make a conversation over 3 posts and finally hit me with that into my face.

It's not nice of me to make you miss a word I clearly posted and used? You need to wear more tinfoil on your head so my mind control rays affect you less.

A very simple situation where the C model fails is: compile a program to Pentium code and let it run on a Pentium 4.

Yes - and that is the case that most Java nuts use to "prove" Java is faster than C. However, it's not the case I was arguing. My point is that if you know your target platform then C will be faster or at least as fast as Java because you can compile it to that specific platform.

In the absolute worst case, the argument falls back to the fact the entire JVM is written in C, so I can happily make the argument that C is provably as fast as Java in every situation simply because Java is really executing C code anyway. Yes - it's cheating but it just shows the futility of the Java argument.

C/C++ optimization is not "cool" in the academic community but it's very much alive and still very much an area that companies spend billions of dollars on. A CPU lives and dies by the efficiency of its C compiler. The same cannot be said for JVMs.

You can express every problem in C that you can express in Java. Excluding C libraries is just stupidity, unless you want to exclude java.lang, java.util and all the other stuff from Java as well, which makes the entire language useless.

So, no. Unless you change the bounds of the argument, fully optimized C will always present the upper bound of performance for fully optimized Java when you know the target platform. To suggest anything else is simple ignorance of how computers work.

Re:If you're optimizing Java, you're sunk

[throx]

A hotspot compiler optimizes for situations the hotspot compiler can detect and adapt to.

A human optimizing C code can optimize for all those situations and more.

C optimization is therefore a superset of Java optimization. Whine about it all you like, but that's the fundamental truth.

Thanks for playing, you lose.

Re:If you're optimizing Java, you're sunk

[angel'o'sphere]

So, no. Unless you change the bounds of the argument, fully optimized C will always present the upper bound of performance for fully optimized Java when you know the target platform. To suggest anything else is simple ignorance of how computers work.

No you can't.

You accuse me to overlook a word you used only once ... and you don't even read what I wrtie.

C compilers work on one compilation unit only, and optimize that oen only.

Jit compiler span multiple compilation units and optimize on that. So Jit compilers for Self and Java and similar languages create faster code than C, and this is true for over 15 years, when the first Self Jits where build and the runtime adaption research started.

Compiled C is not "the upper bound" for speed in relation to other technologies. And as I emtioned there is lots of stuff you can't express in C. Parallel execution, thread synchronization etc. can't be expressed on language level so a compiler can't take any advantages ... how should it, he does not know stuff so it cant use the unknown knowledge. Why do you think languages like Erlang and ML and Occaml are widly recognized as languages that compile to faster code than C does?

angel'o'sphere

Re:If you're optimizing Java, you're sunk

[Anonymous Coward]

Take it easy with the punctuation there big fella. You know what your problem is? That you are trying to apply your "business" logic to everything. And the sad part is that in the real world, not your "business" world where "applications" waste countless resources because of faggy Java "professional" developers, the really real world even Pascal performs better than your beloved POS language.

Stop whining. If you like Java so much go use it for everything you do, but please stop insulting everyone with your claims about better "performance" than C/C++.

Re:Current Economic Status of Prussia

[Anonymous Coward]

And girl, you know that you're the only girl for me, girl
Girl, you're the girl of my fantasies, you're my girl
You're my girl, my girl.

Obligatory

[Bastard of Subhumani]

Coming up later: high performance tuning tips for Citroen 2CV owners.

Re:Oh, please, that's EASY

[Aspirator]

That is pure Flamebait.

Java is a language which benefits more than most from performance profiling, in that
it is very easy to write inefficient code, because the mapping from code to actual
execution is not always very clear.

This is a strength, and a weakness. The degree of abstraction from the underlying
machine is high. This results in quite intelligible code, and an ease of coding complex
and abstract tasks. It also results in it being quite possible to write apparently
simple looking code which ends up executing in a very complex way.

Profiling will expose the gross inefficiencies, and allow them to be corrected.

It will never be possible to write as efficiently (execution time), as
in a more direct language, but the coding efficiency (programming time) is quite good,
and for a lot of applications that matters a lot more. It also has a lot of
cross platform capabilities (not perfect I concede).

I prefer writing code where I can see the bits and bytes (i.e. not Java), but
to put down Java in such an off hand way is unjustified.

Re:Why?

[Anonymous Coward]

If it died a long time ago, why am I still getting paid well to code in it?

Re:My Java Profiler Written in C

[Anonymous Coward]

i wrote one like that for C, it goes like th#@$(JAWDj12309iDAW--

--shit, sorry, must have trashed a pointer somewhere. hang on, this'll just take a minute...

;)

jrat - Already does everything you need.

[tezza]

Forget this article AOP Build Your Own. By the time you finish reading the article you could have used jrat .

Download jrat here

I've used it many times, and it's helped me find horrible Hibernate queries, Lucene bottlenecks, Batik rendering pipeline issues. It is fantastic.

Re:jrat - Already does everything you need.

[andrewwilcox]

The article is more than just how to build an AO profiler -- it's about how to use the Java 5 agent interface to create AO-based solutions. As for jrat -- the big different between JIP (which is discussed in the article) and JRat is that JIP instruments your code at runtime rather than requiring a separate step.

Re:jrat - Already does everything you need.

[Anonymous Coward]

Right...

JRat was written by someone who was high on hairgel fumes at the time. I think this is obvious to everyone involved.

Re:jrat - Already does everything you need.

[Believe]

Sadly, after downloading it and playing with it for the first time tonight, I'm gonna have to agree with this.

Executive summary: the documentation is utter garbage, the last release was more than a year ago, and it doesn't support Java 1.5.

To back it up: they take great pains to hide the forum from users of the site (hint: you have to go to the download page before you can find a link to it), and the documentation doesn't even cover such basic functionality as running in command line mode. The suggested fix to support Java 1.5 didn't work, and finally, the ant target is broken.

Other than the documentation jRat was probably pretty good a year or two ago when everything probably worked (judging from the screenshots), but now it's useless abandonware for anyone working with java 1.5. I'm still looking for a good non-commercial profiler. OptimizeIt is the best I've ever used, but it's expensive.

Re:Why?

[Anonymous Coward]

Maybe because there is no other cross-platform language with decent graphics support and comprehensive libraries?

Re:My Java Profiler Written in C

[Dante Shamest]

Judging by your l33t skillz, even if you'd written in Java, all you'd get would be

java.lang.NullPointerException

.

Glad to see SOMEONE takes performance seriously

[wsanders]

I've worked on quite a few contracts where I was part of a massive 3 ring circus to collect Java metrics, so we could make pie charts for PHBs to show their PHBs. Of course the coders with half a brain already knew where their bottlenecks were. Glad to see all my efforts are being taken so seriously.

jrat already does MOST everything you need.

[JohnQPublic]

Sure, JRat is interesting, but I like the DeveloperWorks article's idea of taking the *exact* bytecode you'll be running and instrumenting it. Now if I can just figure out how to shoehorn it into Tomcat ...

Re:jrat already does MOST everything you need.

[kevlar]

Now if I can just figure out how to shoehorn it into Tomcat ...

You can instantiate tomcat yourself, which means you have full control over the loading of the libraries. Just create your own classloader and inject your instructions as they're read from the JAR.

HP is your friend

[nbvb]

Here you go, be sure to thank HP for them.

http://www.hp.com/products1/unix/java/hpjmeter/ind ex.html
http://www.hp.com/products1/unix/java/java2/hpjtun e/index.html

Re:HP is your friend

[andrewwilcox]

These two tools aren't profilers, there anaylsis tools. hpjmeter uses the output generated by hprof (the profiler that ships with the JDK) and the other tool you mentioned analyzes the garbage collection log. The problem with traditional tools like hprof is that 1: they require native components and 2: they don't let you turn the profiler on and off at runtime and 3: they profile everything -- even things that you as a developer can't change.

Re:My Java Profiler Written in C

[Anonymous Coward]

silent memory corruption or npe w/stack trace, take your pick.

Er, Why is this in IT?

[W. Justice Black]

Seriously. Modifying a program to profile it?

I'd do that, but I'm a hybrid java developer/IT d00d. Most IT folk I know wouldn't touch a profiler with a 10-foot pole, much less write one and semi-build it into an app. This is a programming topic, not an IT one.

Re:Er, Why is this in IT?

[Heembo]

Yea, most corporate slug programmers dont even know how to run a profiler, let alone actually understand the output. Thats why you hire fools like me at 200$/hr or more to run profilers and find your damn bugs for you!

Re:Why?

[Anonymous Coward]

O R L Y?

you really need more than hprof ?

[javaxman]

I know I'm setting myself up, but... do you really have profiling needs that aren't met by hprof ?

Using hprof and decent unit testing, you can work out where your problems are, I've found. All of this bytecode hacking and AOP stuff might show how l33t you are, but I'm not convinced it's really *needed*. Just my humble, uninformed opinion, of course, I'm very willing to hear from others. It could be that I'm just not working on sufficiently complex systems, or that I'm spending more time writing unit tests and pouring through hprof results than most folks.

Re:you really need more than hprof ?

[JohnQPublic]

I've tried to use hprof on complex systems, and it just isn't up to the task. Try throwing a system that has a few hundred threads, a couple of databases, and a servlet container at it. hprof quickly loses track of what's going on and stops recording long before my first servlet gets control.

Re:you really need more than hprof ?

[andrewwilcox]

As was noted in the article, hprof has a number of short falls:

• It is slow. If you've spent any amount of time using hprof, then you know what I'm talking about!
• You can't start and stop it at runtime. If you've ever tried to profile a web application with hprof, you know what I'm talking about!
• Filtering. hprof profiles everything and so it's slow and that output is expansive. When I'm profiling code, I want to know how my code is performing, not how some third party library is performing.

I like hprof -- it's helped me out more times that I can say, but it also has some short comings, which is why I developed JIP

Re:you really need more than hprof ?

[javaxman]

I've tried to use hprof on complex systems, and it just isn't up to the task. Try throwing a system that has a few hundred threads, a couple of databases, and a servlet container at it. hprof quickly loses track of what's going on and stops recording long before my first servlet gets control.

Thanks, that was exactly the sort of post I was looking for.

So, to continue the discussion... do you think the approach outlined in the article would be usable or appropriate for the system you just described ? How might that compare to the AOP approach others have suggested ?

It's interesting that hprof simply stops recording... any theories as to why that would happen? What causes it to lose track of the application state ? Does it have some hard ( or soft ) limit as to how much it can record ?

Re:you really need more than hprof ?

[slamb]

[hprof] is slow. If you've spent any amount of time using hprof, then you know what I'm talking about!

That's true for the timing mode. The sampling mode is zippy. For most stuff that I do, it's good enough. It's generally pretty obvious which are blocking calls and which are actually using the CPU. Monitor contention can be a bit confusing sometimes, though - a relatively simple operation will have many, many samples because it's waiting on a monitor held by something more complex. This is good to show you that it's an important problem, but it doesn't make it obvious where to go to fix it.

I tend to use this configuration:

export JVM_PRE_ARGS="-agentlib:hprof=cpu=samples,interval =10,depth=5"

...and I sometimes change the "5" as necessary. There's also a heap allocation mode that I haven't played with much, and something that shows you each monitor acquisition and deacquisition (which I think is too much information).

You can't start and stop it at runtime. If you've ever tried to profile a web application with hprof, you know what I'm talking about!

Yeah, but with the sampling mode, I find I can just leave it on all the time on my development system.

Filtering. hprof profiles everything and so it's slow and that output is expansive. When I'm profiling code, I want to know how my code is performing, not how some third party library is performing.

Why? I want to know if I should patch or replace a third-party library. I care about the performance of the whole system, not just the code I wrote.

Re:you really need more than hprof ?

[linuxhansl]

You can't start and stop it at runtime. If you've ever tried to profile a web application with hprof, you know what I'm talking about!

This is a common problem with badly designed software. Software should be designed so that all parts can be unittested - and hence profiled - independently. Not only will such a design facilitate better and easier testing, it also makes the code more readable, extendable, and reusable.

Re:you really need more than hprof ?

[JohnQPublic]

I have no idea why hprof gives up the ghost, and lacking source code I never investigated it. As to AOP, I think it's a bad idea. I don't want to recompile my code to profile it, I want to profile the code I've compiled. Not often, and not on a predictable basis.

That's why I like the bytecode-injection-at-load-time idea - it works with normal code. If I think the code is too slow under the profiler, I can run the same class files without the profiler and see if it's the application or the profiler that's slow. If the former, I've got a problem. If the latter, well, that's how profiling works.

There's still the problem of getting a javaagent mechanism working with a complex system, but that's probably just a case of coding the class-recognizer well. The overhead of having it examine and ignore 75% of the classes that are loaded shouldn't be too high.

For the record, I think Aspect Oriented Programming is a train wreck looking for a place to happen. The only legitimate use for it is exactly this kind of problem, and then only in non-production environments. Harbison said of Object Oriented Programming something that I think bears on AOP in spades:

      "... the ability to define your own operator functions
      [in C++] means that a simple statement such as x = a +
      b; in an inner loop might involve the sending of e-mail
      to Afghanistan."

And in AOP, you'll never know that it happens from reading the source code.

Re:you really need more than hprof ?

[javaxman]

And in AOP, you'll never know that it happens from reading the source code.

You and I are so on the same page, it makes me smile a little. I officially apologize for pushing the hprof debate just to get this comment out of you, by the way. I think the injection technique looks pretty cool, as I'd much rather do that than modify ( and then have to change, by hand, again ) the source code to place timing information.

On the other hand, I'm a huge fan of writing unit and 'prototype' tests, although I understand those don't always show the source of problems in already-deployed very large systems.

For the record, my experience shows 90% of those problems end up being SQL queries, FWIW.

Re:Why?

[animaal]

I agree totally. Java is dead. We just have to get the message through to the huge numbers of organizations and developers who depend on the technology to get their jobs done. Oh, and then we have to come up with something better to replace it. Give me a little while... ;)

A generalized profiler is just what I need now!

[Anonymous Coward]

The idea of being easily able to measure where a program is using resources appeals to me. It might settle a few arguments around here.

Programming in C with a monkey chewing on your arm. I see students doing that all the time. They struggle for hours to write code that they could do in minutes with a higher level language. They look like they are having about as much fun as if they had a monkey chewing on their arm for sure. Usually, for what they are doing, speed of execution is irrelevant.

I often hear C programmers insist that they can be as productive as someone writing in a higher level language. They say it's just that the people writing in the higher level language never learned to program properly. Actually they're right about that one. Many people who get paid to write in higher level languages aren't really good programmers but that doesn't prove anything about the innate goodness of the languages in question.

We have gotten to the point where being able to write at a low level isn't as advantageous as it used to be. For instance, it used to be possible to write key elements of code (for DSPs in my case) in assembler. With modern tools, that advantage has evaporated. Trying to code by hand often creates much slower code. (Actually in this case, C is the higher level language.)

My own preference for a higher level language is Python. The large majority of the time, there is absolutely no useful benefit that I could get by writing in C.

Anyway, your comment about programming in C with a monkey chewing on your arm, reminded me a lot of an ongoing argument with the people who teach programming around here. The students do need C because they do a lot of embedded stuff, but the rabidity of some of the C folks does seem a bit overboard. Sorry if you got caught in the crossfire.;-)

Re:A generalized profiler is just what I need now!

[TheNetAvenger]

Programming in C with a monkey chewing on your arm. I see students doing that all the time. They struggle for hours to write code that they could do in minutes with a higher level language. They look like they are having about as much fun as if they had a monkey chewing on their arm for sure. Usually, for what they are doing, speed of execution is irrelevant.


This not something we disagree on, whatsoever... In fact my past post supporting higher level languages and help from IDEs have not been received so well.

I think there is a balance, programmers can't be fully dependant on a good language and an IDE that does everything for you, as they never get the 'creative' element a lot of times, as things are done for them, instead of them having to 'figure them out', as us old time coders had to struggle with, but also gives us the creative edge. When we had to create our own way for something to happen in C or C++, that gave us the understanding and sparked our creative elements.

However I am all for the higher level language technologies and ease of use from IDEs. Why not let the language and the IDE do a lot of the work, when they can do it with performance or reused concepts, and are smart, considering the processing power we utilize today, then why not use it?

Just because I know how to drop to a low level language or hand code button coordinates for a form, doesn't mean I should have to with current development technologies. The IDEs should be smart and do a LOT of the work for us, and the languages we choose can also be high level and do a lot of the work for us. Even Delphi Pascal, VB, C# are good examples of this, Pascal not only provides speed, but memory clean up that non-existent in many C forms.

So with that all said, I DO NOT thing JAVA is a good example of a high level language or a good solution. Why use JAVA when I can just as easily code in numerous other languages and IDE environments that do all I described above for me, and yet get near C/Assembly level of performance. Why should we suffer SUCH a performance and 'stability' and 'consistency' hit by using JAVA.

If JAVA was 'fast', more stable, and truly platform independant, I would be here championing JAVA. I was an early fan, but SUN Never delivered. It doesn't do any of the original design goals. Heck I could even eat some of the performance hit if it did run reliably across multiple OSes, and it just doesn't at least not yet, and will be probably be too late before it matures to the level needed and these other tools are already filling in the needs.

Take Care,
TheNetAvenger

Quick! Name a successful Java program.

[Anonymous Coward]

Nope. I can't think of one either.

Re:Seriously

[Anonymous Coward]

"java to native binary" and "portable"

what are you smoking?

Re:Why?

[Anonymous Coward]

Other than Mono, none of those even remotely compares to Java and there's numerous reasons why to use Java over Mono. I love it when the topic is performance and people suggest Python/Ruby/Perl etc., it just shows that they're completely clueless. For most real world *paid* developers the choice is between .NET and Java, each having their respective strong points.

"not responding" checker? Anyone?

[maillemaker]

I'm looking for an application that will monitor a specified application and log how long the application is "not responding".

We use CAD (Computer Aided Design) software, and I would like to justify new hardware by being able to say how much less time we would have to spend waiting on the software if we had faster computers.

If I had a way to measure how often the cursor was an hourglass in our CAD software during the course of a standard workweek and then benchmark this on a new computer I could have a metric that I could use for justification.

Anyone know about anything like this?

Steve

Re:Quick! Name a successful Java program.

[Anonymous Coward]

How about walmart.com?

Java startup annoys me greatly

[metamatic]

Java's a speed demon compared to almost all other programming languages out there.

Depends what you mean by "speed". For example, compare how long it takes to fire up ANT, compared to Ruby's Rant. Both are build tools offering roughly equivalent functionality.

Results:

$ time ant
Buildfile: build.xml does not exist!
Build failed

real 0m1.233s
user 0m0.188s
sys 0m0.043s
$ time rant
rant: [ERROR] No Rantfile found, looking for:
Rantfile, rantfile, root.rant
rant aborted!

real 0m1.071s
user 0m0.089s
sys 0m0.015s

Ruby's an interpreted language, and it's one of the slowest in its class. (Slower than Python or Perl). It's loading in all the libraries as source code and interpreting them. Yet it still wipes the floor with Java at speed of startup. And that's before you actually start building anything--the first time I used Rant, it was so much faster than ANT that I thought I must have done something wrong.

Try launching a major Java GUI application, and you can profile the application startup speed with a manual stopwatch. Try launching a J2EE setup, and compare it with starting up Ruby on Rails.

Java isn't going to lose its well-deserved reputation for slowness until some major work is done on startup speeds.

(And yes, I'm using Java 1.5.0.)

Re:Java startup annoys me greatly

[moro_666]

nobody will ever optimize java for your specific needs.

java right now is fast where it's supposed to be, in large serverside applications running in multiple threads and having a stable platform all around it. if you've got 50 threads up and running , all doing various sort of fast i/o and depending heavily on automatic garbage collection, java sweeps the place clean. python is dead, perl doesn't even have proper threads (ithreads are not really that much of "thread" ...), ruby with 50 threads ? right ....

and you are comparing this to a 5 liner scripting language .... doh

starting an entire platform is a lot more than reading a dummy script.

i could aswell claim that a damn ruby/python/perl thing sadly dies if it goes over 100 threads all fighting over db connection pools and managing a shared memory of 1gb ... these things aren't even comparable so why do you bother ?

Re:Java startup annoys me greatly

[angel'o'sphere]

If you compare ant and rant in that way, then you compare two programs, not to languages or language environments.

Guess what ant is doing all the tiem while it is using your CPU? It loads an XML parser, it loads an XML Schema (likely via the internet) and it laods some ant taks and finaly it wants to open a file that is not existing ...

Sure, for your little benchmark it would be much better to open the file first and abort early ...

Rule number one in meassuring and benchmarking: get a clue what you measure.

angel'o'sphere

Re:Java startup annoys me greatly

[metamatic]

So ANT is badly designed, that doesn't discount the point. I also mentioned J2EE environments vs Rails, and you'll get the same Java speed problems if you try "Hello World". Face it, Java startup is goddamn slow, and trying to deny it doesn't make the problem go away.

Re:Java startup annoys me greatly

[metamatic]

So if Java I/O is so fast and it's a compiled language, why does it take an order of magnitude longer to start up than any other language runtime except Smalltalk or C#? What could it possibly be doing that other language runtimes don't have to do?

And I'm not just talking about 5 liner scripts. I mentioned Rails, which does database persistence, XML, and the other web application things a J2EE environment does--and starts up 10x faster than any J2EE setup I've seen.

Sure, Java threading is good. The point is, you don't necessarily need 50 threads in Ruby, because you can afford to start more than 1 process.

So am I to take it you're admitting that Java is totally unsuited to desktop applications and the embedded applications it was supposedly designed for? Isn't that rather a sad reflection on the language?

(I'm coming at this from the perspective of someone who would like to be able to write useful desktop and mobile code in something other than the crappy languages I'm stuck with at the moment. Java's slothfulness at starting up means it isn't a very good option, and I'd like to see that change. Saying "La la la there is no problem because I run everything on the server" isn't really a very helpful response.)

Re:Java startup annoys me greatly

[Phil John]

The reason it takes so long to startup is because you have the overhead of:

• Loading the JVM
• Reading and Verifying the ByteCode of the classes to be loaded
• Running a JIT compile cycle to get your optimised machine code
• Starting execution.

All of that takes time, that's why it takes so long. Ruby on the other hand has the overhead of:

• Loading the interpreter
• Opening a ruby script

After that it simply follows the instructions in the script...slowly (by comparison, but not in the grand scheme of things).

It's a given that startup times can be a bit on the long side for Java apps, however, how many times do you start an IDE in a given day? How many times does that J2EE app have to start (if the programmers knew what they were doing not very often).

Being a slow starter does then mean you don't want to write a console app that munges some data quickly and then exits...that's just silly...use perl/c/whatever instead. For large apps that are started infrequently, it's not so clear cut.

As for ruby in an enterprise app, it may start faster but which one serves request faster and which one scales better? I think you'll find it's a well configure J2EE stack.

Re:Java startup annoys me greatly

[Anonymous Coward]

It loads an XML parser, it loads an XML Schema (likely via the internet) and it laods some ant taks and finaly it wants to open a file that is not existing ...

WTF?! No it doesn't. ANT's build scripting is schema-less - in fact, it can't be defined by a schema, because you can define new XML elements via the <taskdef> command.

Plus, in his example, ANT isn't loading ANYTHING. It's going far enough to ask the Java I/O library if "build.xml" exists and that's it. Because it doesn't, it never loads the XML parser, and never loads the stuff that makes an empty ANT script take a good second on a modern P4 to do absolutely nothing.

(Seriously, time <?xml version="1.0"?> <project/> and see how long it takes.)

If you really want proof of just how slow Java is, run ant -projecthelp on an ANT script, and time that. It takes it over two seconds to display the project help on a 9KB ANT script on my machine, a 3200+ AMD K7. Keep in mind that when it displays the project help, it doesn't even bother parsing the inner XML, just the <target> elements!

A simple time ant gives me 0.692s on my system - keeping in mind that this is AFTER I've already caused the JVM to be loaded by the ant -projecthelp!

The Java startup time is, simply put, INCREDIBLY slow. When you start loading anything complicated, the massive number of classes that get loaded slows things down even further.

As a comparison, running a Perl script that does nothing takes 0.027s on my machine.

Re:Java startup annoys me greatly

[angel'o'sphere]

The Java startup time is, simply put, INCREDIBLY slow. When you start loading anything complicated, the massive number of classes that get loaded slows things down even further.

That was my point.

I assumed that ant starts with loading a massive amount of classes ;D and I did not guess it needs no schema definition.

angel'o'sphere

The most portable paradigm ...

[Anonymous Coward]

./configure
make
make install

here's my profiler

[cygnus]

public class HomegrownProfiler {

public static void main(String[] args) {

while (true) {

System.out.println("Some people say this'll never be quite as fast as hand-tuned C.");

}

}

}

Re:here's my profiler

[coshx]

% Some people say this'll never be quite as fast as hand-tuned C.
% Some people say this'll never be quite as fast as hand-tuned C.
*snip*

Well, I think it really depends on whether you downloaded the hand-tuned C as a pre-build binary or compiled it yourself...

Re:Quick! Name a successful Java program.

[Anonymous Coward]

"Quick! Name a successful Java program. Nope. I can't think of one either."

Gmail. It uses Java for almost all of its back end. In fact almost all of Google's large scale web applications use Java in some form. Python is also used extensively however, it's generally used for simple scripts and smaller applications. Tons of websites use Java extensively and people like you are just too dumb to realize it. If you do online banking it's almost guaranteed that the website is using server side Java.

In terms of client side applications there's; Azureus, LimeWire, Eclipse, Netbeans, Intellij IDEA, Yahoo Site Builder, ZipCreator, Summit Groupware, jEdit, SmartCVS, NeoOffice etc. etc. Just because you don't use them doesn't mean that they're not there. The truth is that most people only use a very select few programs and these programs are often using code bases that are over 10 years old (ie. Microsoft Office, Outlook, Internet Explorer etc.). Then there's all the enterprise applications that are written in Java.... In the enterprise world Java is dominant and the only real competitor is .NET.

Re:Why?

[Anonymous Coward]

I said language.

perl - illegitimate offspring of bash and grep.

python - perl for people who hold their little fingers up when they drink tea.

mono - I had that as a teenager

tcl - heh heh

Re:"not responding" checker? Anyone?

[Billly Gates]

You need a real unix like solaris for this feature and not linux.

Although I heard linux has limited support for profiling these days I dont know how good it is for monitoring regular applications in userspace.

best-of-breed

[teneighty]

Never use the word "best-of-breed" again. Or else.

Re:best-of-breed

[Anonymous Coward]

This paradigm is a quantum leap for leading edge enablers. It's an enterprise-class, state-of-the-art construct in this solution space. I suggest you recontextualize your core competencies.

Re:Why?

[Zebra_X]

Oh wait, do you mean .NET? :-) And while you are downloading the "free" IDE, you can also pick up one of several
visual code profilers out there.

sorry, Windows based...

[maillemaker]

Sorry, we are on Windows. They don't even write a *nix version of this software. Anyone know of a not-responding process monitoring app for Windows? Steve

Re:sorry, Windows based...

[Billly Gates]

Let me guess"? Autocad?

Its a shame the cad market is going to windows from unix. Its certainly no unix and the vendors drank the NT coolaid from all teh hype in the 90's.

For filtering, I've also got another option

[fizbin]

This perl script. (Or google for "wherehot.pl")

It's a relatively simple script I wrote a while back to filter hprof textual output. It tells you things like "which of the code inside com.foo.* is being slow"? And "which of the code inside com.foo.* is causing StringBufffer.expandCapacity to be invoked, and thereby being slow?".

A further enhancement of it (that I haven't posted yet, sorry) changes the output format to look something like a java stack trace, which means you can take the output of that script, copy and paste it into eclipse's Java Stack Trace console, and be able to click on the lines identified as being slow.

We've found it to be a nice complement to graphical tools that let you visualize what bits are slow, like HPJmeter.

Re:Quick! Name a successful Java program.

[Anonymous Coward]

I love when people try and use server applications to prove that Java is useful. Yeah, when you can throw as much server hardware as you need at a problem, you can get Java to work. But just because Java works when you shove enough server power under it doesn't quite make it a lean, agile platform. There are successful web applications written in Visual Basic, after all.

In terms of client side applications there's; Azureus, LimeWire, Eclipse, Netbeans, Intellij IDEA, Yahoo Site Builder, ZipCreator, Summit Groupware, jEdit, SmartCVS, NeoOffice etc. etc.

Let's see, Azureus, which is well known for massive CPU and RAM usage, LimeWire, which as I recall is slow and buggy, Eclispe, which is slow and flakey, Netbeans, which flat-out sucks...

It's interesting you should mention jEdit. You might want to read the developer's blog where he explains why Java sucks ass, and why he'll never touch Java ever again.

The simple reality is that Java isn't used for anything useful, or any place where a simpler language couldn't have been used to create a faster, more scalable, dynamic solution. The people claiming otherwise are deluding themselves.

java is crap

[AlgorithMan]

if this profiler is written in java (likely) it is as slow as the crap it's supposed to analyze...

Re:java is crap

[joe_n_bloe]

You don't have the foggiest clue what you are talking about.

Class rewriting is cool, and can be done on a live JVM, even multiple times for the same class if desired. The result runs just like the original unmodified class. It's like *func = sub { print "new sub" } in Perl, but with much greater control and granularity.

Anyway, don't be such a tard in public.

No, not Autocad

[maillemaker]

No, it is CoCreate OneSpace Designer.

>Its a shame the cad market is going to windows from unix.

I think you meant "from unix to windows"?

I'm not surprised. CAD is becoming more and more a commodity - it is currently running about $5000 a seat for stuff like SolidWorks or Pro/Engineer. There are less and less dollars to spend on things like multi-platform support.

Windows is the predominate desktop environment.

Personally, I don't care what the platform is.

Steve

Re:No, not Autocad

[Rudolf]

Okay, this is off-topic, but what the heck. This comment made me curious...


>Its a shame the cad market is going to windows from unix.

I think you meant "from unix to windows"?

I must be missing something. Is "to A from B" somehow different than "from B to A" ???

Re:No, not Autocad

[Anonymous Coward]

Yeah, probably, in assembler.

Amen

[Anonymous Coward]

Actually, I have avoided Java like the plague. When I decided to dump Windows and run Linux I had zero Linux or Mac experience. I was looking for a language that would be cross-platform. I was considering Java but then there was a story on Slashdot. The story said that developers at Sun didn't think Java was very good in their programming environment. They recommended a couple of languages and Python was one of them.

Here's a link:
http://www.internalmemos.com/memos/memodetails.php ?memo_id=1321

Re:Amen

[TheNetAvenger]

Actually, I have avoided Java like the plague. When I decided to dump Windows and run Linux I had zero Linux or Mac experience. I was looking for a language that would be cross-platform. I was considering Java but then there was a story on Slashdot. The story said that developers at Sun didn't think Java was very good in their programming environment. They recommended a couple of languages and Python was one of them.

A good environment was Kylix and Delpi (pascal) from Borland for Linux and Windows. Fast compiler, fit both OS frameworks, etc etc.

Borland didn't get the support in the Linux community and has let the Kylix portion slide. Inquire, show them some support or encourage them to open up part of the project for others to help with.

Good old fashioned C/C++ works the best for moving from platform to platform. There is always a Good C Compiler, but that is not always the easy solution. In Windows you get help with .NET or even the VCL technologies, but in moving to other OSes you ahve to recreate or use the equivalent technologies and that requires a lot of rework on some things.

One reason to do your own instrumentation

[joe_n_bloe]

We have a product that requires that profiling be done on a per-object basis. I'm not using the Java class transformer interface, but I am rewriting classfiles in a manner similar to hprof's bytecode instrumentation option (as opposed to the stack sampling option), using JVMTI.

JVMTI + JNI is pretty slick stuff. The source code to hprof comes with the JDK 1.5 release and is very informative, if overwhelming at first. If I instrument methods very selectively, the effect on runtime speed is minimal.

OTOH, trying to implement something like this for Perl (my favorite language) would be an exploration of pain the likes of which hasn't been experienced since people were broken on the wheel.

Re:One reason to do your own instrumentation

[Anonymous Coward]

OTOH, trying to implement something like this for Perl (my favorite language) would be an exploration of pain the likes of which hasn't been experienced since people were broken on the wheel.

Implementing the same thing using JVMPI and JNI would be a similarly painful exercise for those of us who can't use Java 5.

Re:One reason to do your own instrumentation

[joe_n_bloe]

It would be kind of pointless too, with JVMPI being deprecated and soon going away.

Mercury's Profiler

[broody]

I prefer Mercury's profiler. Its for J2EE or .NET applications but it integrates with Load Runner and Business Availabillity Center. There is a free trail here.

IDE/platform integration is, well... integral

[The Waxed Yak]

Look, nobody is using notepad/vi and javac these days to develop anything. And most of the Java software we develop these days doesn't simply run from the command line. Be it a J2EE application or an Eclipse RCP application, most *free* (as in speech or beer) tools don't do the greatest job when dealing with a predefined configuration, such as the aforementioned.

Please, someone prove me wrong on this, but I can't seem to find a decent code profiler for use with J2EE or Eclipse RCP applications. You can't simply launch them in a JVM and have your way with them.

I have used some plugins for Eclipse that almost do an OK job of this, but even they are limited. The best I've found to-date is:

http://sourceforge.net/projects/eclipsecolorer

Even this one has major warts, though. Such as it only runs reasonably on Windows, while I do most of my Java development on a Mac these days.

I'm sure someone will come along and suggest JProbe, or another commercial product. If the price were right, I'd by any of these as well. Unfortunately, for the moment, it is more cost effective to pepper my code with Log4J statements providing profiling information in the form of a log file and to parse the results myself.

Again, if anyone can prove that I'm incredibly wrong, I'll buy you all the beer you can drink the next time I'm "in your neck of the woods."

Re:IDE/platform integration is, well... integral

[Anonymous Coward]

Netbeans has a pretty good profiler, much better than anything for Eclipse (I haven't found any good profilers for Eclipse either, though it's a good IDE)

http://profiler.netbeans.org/

Re:IDE/platform integration is, well... integral

[Anonymous Coward]

Look, nobody is using notepad/vi and javac these days to develop anything.

Correction: none of the Java weenies^Wdevelopers. I suppose all the "professional" developers like their "IDE" to eat 90% of the workstation's resources. Loser.

Please stop. You're wrong. Get over it.

[ttfkam]

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

Re:Please stop. You're wrong. Get over it.

[cecom]

Very interesting read, thanks. It does show that in practice Java is fast enough, but it doesn't address my point. Too many things are omitted - restricted pointers, manual cache control, etc. I could delve into the specifics but I doubt anyone would read that om Slashdot.

For one the paper doesn't even mention the pointer chasing problem, which is inherent in the definition of the language. In Java almost everything is an object reachable through a pointer - accessing the object means stalling the CPU until the memory load of the pointer itself has completed. In loops this leads to easily measurable slowdown of at least 10x. A not that uncommon worst case scenario is an array of complex numbers or 3D coordinates. It is possible to work around the problem by using separate arrays for each component, but doing that in a high-level language like Java is a shame, not to mention extermely inconvenient.

As I said earlier, matrix calculations do not necessarily have this problem since they most likely use single-dimension arrays of primitive values. When the range checking is eliminated, there is no fundamental reason why accessing an array of primitive values should be any slower in Java compared to pure C. It all depends on how expensive optimizations can be done by the JITter at runtime. I doubt a JIT will do complex code reorganization optimizations, but it is possible.

Generally speaking, achieving high performance always requires fine-tuning, which is all but impossible in Java. You can't examine the generated code, you can't affect how the GC allocates memory, you can't selectively use assembler (JNI is too expensive), you can't selectively enable optimizations, you can't manually insert prefetch or cache control instructions in the generated code. You are stuck with what the current JIT does and there is no way to improve that. If experience has taught us anything, it is that there is always room for improvement. The problem is when you can't get to it.

All the performance problems specific to "C" mentioned in the referenced paper - e.g. aliased pointers, cache unfriendly memory allocation, etc - are solvable in C using restricted pointers, a custom memory allocator, etc. On the other hand the problems specific to Java cannot be fixed without modifying the language or at least the JIT compiler.

Let me put it another way. A hypothetical situation. Assume that you are an expert in both C and Java. You are given the task to write the fastest possible implementation of some algorithm. You are given plenty of time compared to the complexity of the algorithm. You can use either Java or C. When you are done, your implementation will be benchmarked against others (e.g. mine) and the author of the slower one will be killed. Which language would you choose ?

For the fanatics I would like to point that this has nothing to do with liking or disliking Java or saying that it is too slow. Java is a lot more robust and cost effective than C/C++.

Good Lord, Why?

[Anonymous Coward]

I can't see why you would do this, except as an exercise. I've used JProfiler on clients' apps for a long time now, and I couldn't imagine that I could write something better and more comprehensive myself.

--It allows me to filter on only the classes I want.

--It provides good reports. Not only are these nice for the Brass, but nice for including in reports to other developers.

--It's stupidly easy to set up and use. That stuff from the Eclipse plugin looks a lot more time consuming and tiring to view than the visual representions of my objects JProfiler gives.

--True it does not run on ALL platforms. I guess that could be considered a downfall. But still, with Java, I have many times profiled an app on my dev machine, when that is a different platorm than the prod machine. Not ideal, but it sure gets you miles further down the field than not profiling at all.

True, it's not open source, but honestly what tool this good is? *ducks* That was a joke, but I don't agree with the article that OS should necessarily be a feature of the "ideal" profiler.

True it does cost money to license. But hey, it's my business. I don't mind investing a little money for something as critical to my business as a Java profiler.

You're asking the wrong question

[radtea]

That's simply not true. I work on a large Java project that deals with a lot of matrix intensive work. Our Java code has been rigorously architected, engineered, and optimized.

It is meaningless to ask, "Which is faster, Java or C++?" because how the compiler, not the language, has a very large effect on that. People who claim that Java is fast because their favourite JVM happens to have some particular optimization they like are barking even further up the wrong tree, because the only speed that matters is the speed that users actually get, rather than the speed that users would get if they were running a JVM other than the one they were actually running.

It is more meaningful to ask: How easy is it to do things really badly in Java vs C++? The answer to that is: it is very easy to write extremely slow Java code, and very easy to write extremely fragile (and leaky) C++ code. I've managed large Java projects and seen how fast good programmers can make Java go, but I've also seen how slow merely average programmers can make Java go. And how much of a resource hog Java can be in the hands of average programmers (and on average VMs). Likewise, my own C++ code is clean and robust, but I've worked with developers who just aren't safe to let near a C++ compiler. Invalid iterators aren't the half of it.

The fact that extremely good programmers can make Java apps fast does not make Java a "fast language" any more than the fact that extremely good C++ programmers can make C++ apps safe makes C++ a safe language. It will always be really easy to write Java apps that move at the speed grass grows and use up all the memory in the machine, and it will always be really easy to blow you whole leg off with C++. Both languages require really good developers to use them well.

Re:Quick! Name a successful Java program.

[Anonymous Coward]

Most of your comment is idiotic and I'm not going to reply to most of it. As for your accusation about Slava, I know him personally and he's an extremely intelligent programmer. Of course what you fail to mention is that he thinks that practically every language available today sucks and has poor design and implementation. To some degree he's probably correct. The only language he really likes is Lisp and that's why he's gone on to create Factor. Of course when you're bashing Java it's nice to bring up that he doesn't like Java, however people that do this always fail to mention that he hates almost every other language equally or more so.

The points you've made against Java are also pathetically weak and unjustified. They're also nowhere near the same issues that he has with the language. Come to Freenode if you would like him to tell you himself.

Yourkit YJP Re:JVMPI

[speculatrix]

At $JOB-1 I trialled and bought Yourkit's YJP, which is truly excellent, very easy to use and a very effective tool. Moreover, it's not expensive, and the support is pretty good too. I'm just a happy customer, not affiliated in any other way.

What AOP does not solve...

[chiraz90210]

I've written my own java profiler/coverage tool using JVMTI, JNI which publishes results on a dynamic webpage (see Patty @ SourceForge ). One of the problems when maintaining statistics on execution and line number coverage if you keep it in the same JVM is that it has a large performance impact to continuously look up the buckets (like many profilers do), the buckets where the statistics are kept. So one of the things is to bring down this impact by only profiling certain classes, plus sending all the profiling data to a separate computer, which has CPU available to put the data into the stat buckets to be extracted later. (this is the process that is costly to do inside the same process, putting stats into the correct buckets, due to `lookup` code ). I'm using a Tomcat process to gather data for example on a simple text-based protocol. With ByteCode Engineering (called bytecode instrumentation in this case) rather than AOP, the advantage is that you can reload the class later without the instrumentation. AOP is not that flexible. So the advantage is that without any instrumented classes, if your environment is set up correctly, you can even start profiling in production if you wanted to (I would highly recommend not to though). The other benefit of native profilers is that you can put this profiler under every JVM, even code that you don't know anything about, and it allows you to profile anything at will without writing specific AOP junctions or other stuff. (let's not assume you only want to profile your own 'known' code?) JVMTI also allows you to analyze the objects on the heap. If you look into the Sun API, you can see there are various functions to tag objects, which cna be used to filter on specific objects only. I'm using this to make an estimate how many instances of certain objects there are and how much memory they are using. Sun comes out with their own implementations (JFluid for NetBeans) and jconsole. So the benefit of future projects is that it must be aimed at a specific problem not yet solved. My project on SourceForge has full source code available if you wanted to have a look how it works (C and Java). (GPL / Mozilla, you choose)

Re:Oh, please, that's EASY

[owlstead]

"It will never be possible to write as efficiently (execution time), as
in a more direct language.."

Well, obviously, theoretically you're right. But in practice some Java applications that run under JIT can actually go faster as, e.g. C++ code. Especially if you take some common coding practices in C++ (heavy use of copying constructors etc).

I use JProfiler and heartily recommend it

[Hazelnut]

When I need to do some profiling I use JProfiler (http://www.ej-technologies.com/products/jprofiler /overview.html) and it's pretty good. Still some things which could be improved, but most certainly better that anything else out there two years ago when I did some Java profiler research.

Also a very cool company, as I have had personal replies to my enquiries regarding certain aspects and suggested enhancements...

Not to me...

[maillemaker]

>I must be missing something. Is "to A from B" somehow different than "from B to A" ???

I'm not sure what you mean. The fellow was (I think) trying to lament how the CAD market was going from unix to Windows (though he /said/ "windows to unix" - I think he meant "unix to windows" since I was saying our software was only available on Windows).

As I said - I don't care what platform the software runs on.

Steve

Re:Not to me...

[Anonymous Coward]

He said to Windows from UNIX which is the same as from UNIX to Windows, you fucking idiot. Are you even supposed to be NEAR a fucking computer, let alone CAD software, if you fail simple logic such as this? I fucking hope I'm not gonna use shit you design. Retard.

And regarding the not caring part, why the fuck do you feel the need to share this? Are you proud that all you can do is clicky with the mouse? There was a time when serious people did serious shit (CAD is serious shit, right?) on UNIX, now it seems like they let any idiot do it.

You are one of the people I'd run over with my car, that is if mom gave me the money to buy one and get out of her basement.

FOAD.

Re:Quick! Name a successful Java program.

[flamdrag]

Would the Apple store and the iTunes Music store be considered successful?

Re:LOL at Java and Performance in the same title

[Anonymous Coward]

Yup, bothering to run a profiler on your Java code is like ricers fixing up econo boxes. If performance is important, try starting with something fast.

It's been 11 minutes since you last successfully posted a comment

(It was in a goddamn journal, for chrissakes. That was my first post to Slashdot all day, and this is my second. It's not like I'm fucking flooding the system.)

I Wrote 2 Articles on Monitoring with AspectJ

[rbodkin]

In fact there are two articles on DeveloperWorks that I wrote last fall that describe how to use AspectJ to do more advanced performance monitoring (that are cited in the original article). See http://www-128.ibm.com/developerworks/java/library /j-aopwork10/ and http://www-128.ibm.com/developerworks/java/library /j-aopwork12/

The big benefits of using AspectJ are the ability to build more interesting coherent logic with a higher level language rather than (virtual) assembly language, and to have a well-document, accessible extension language for custom monitors.

Ron Bodkin

Re:I Wrote 2 Articles on Monitoring with AspectJ

[javaxman]

In fact there are two articles on DeveloperWorks that I wrote last fall that describe how to use AspectJ to do more advanced performance monitoring (that are cited in the original article). See http://www-128.ibm.com/developerworks/java/library /j-aopwork10/ and http://www-128.ibm.com/developerworks/java/library /j-aopwork12/

I wish I could mod that up. Obviously I missed the references in the original article. Thanks.