Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Build Your Own Java Performance Profiling Tool 153

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.'"
This discussion has been archived. No new comments can be posted.

Build Your Own Java Performance Profiling Tool

Comments Filter:
  • by Anonymous Coward on Tuesday March 14, 2006 @04:19PM (#14918710)
    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?
  • by Aspirator ( 862748 ) on Tuesday March 14, 2006 @04:31PM (#14918801)
    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.
  • by andrewwilcox ( 961166 ) on Tuesday March 14, 2006 @04:40PM (#14918881)
    You're implying that there are languages (other than Java) that don't ever require profiling which is simply rediculous.
  • by vectorian798 ( 792613 ) on Tuesday March 14, 2006 @04:45PM (#14918916)
    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.
  • by Anonymous Coward on Tuesday March 14, 2006 @04:48PM (#14918946)
    silent memory corruption or npe w/stack trace, take your pick.
  • by ultranova ( 717540 ) on Tuesday March 14, 2006 @04:51PM (#14918976)

    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 [apache.org], for example, is written in Java. Admittedly, it is much slower than Inkview [inkscape.org] 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.

  • by Anonymous Coward on Tuesday March 14, 2006 @05:04PM (#14919074)
    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.;-)
  • by Heembo ( 916647 ) on Tuesday March 14, 2006 @05:20PM (#14919196) Journal
    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!

  • 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

"Here's something to think about: How come you never see a headline like `Psychic Wins Lottery.'" -- Comedian Jay Leno

Working...