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.'"
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.
You're implying that there are languages (other than Java) that don't ever require profiling which is simply rediculous.
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.
.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.
Also, your mention of DirectX having
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.
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.
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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!
Horns are really just a broken halo.
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
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
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.