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.'"
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?
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.
silent memory corruption or npe w/stack trace, take your pick.
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.;-)
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.