todo.txt

Eclipse profiler plugin,Profiler 性能跟踪、测量工具

[+] - done
[*] - in progress

[+] 1. Remove 10000 methods limit.
[+] 2. Add source code.
[+] 3. Add connecton to remote application.
[+] 4. Plugin profiling, something like PDE launcher.
5. Problem with HeapViewer (display is not valid?).
[+] 6. Exception in TERMINATE handler (terminate of thread?).
[+] 7. Profiling in debug mode. Clear statistics action.
      I got an app that i am suspicious of using way to much time in an certain
      part of the program, im just not sure exactly of where the problem is.
      I run the app to its completion with the profiler enabled and can see the
      actual numbers. But those numbers are for the whole apps lifetime, so the
      numbers can "lie" (or at least hide the truth). Thus I want to set an
      breakpoint where I think the problem is, start it with the profiler enabled,
      the app runs to the breakpoint and I can then examine the current
      accumulated numbers. I (optionally) reset the accumalted numbers and set a
      new breakpoint at a second point and continue the program....and now i can
      again get a new accumlated view...So, it is just to be able to easy to
      pinpoint and investigage the critical points. (It would be a big plus if the
      normal debug facilitites, such as inspection, variables view etc. could be
      available also....)
[+] 8. Pause/resume all threads.
[+] 9. Configuring refresh rate (currently 5 seconds).
10. Use some heuristics for detecting small methods. Jon Skeet:
      Out of interest, doesn't this affect inlining? Namely, short methods 
      which otherwise wouldn't have taken much time at all, due to being 
      inlined, suddenly don't get inlined due to the call to the profiler, 
      which affects the profiling.
      Not that I can think of a way round it, but I would have thought it 
      would impact the accuracy significantly.
[+] 11.   Total time column and call diagram.
        A suggestion for the future: The Time column in the methods tab  seems  to
      measure how much time was spent in that method itself. It would be useful to
      also have the ability to see how much time was spent in  a  method  and  all
      methods that were called by this method. Borland's Optimizeit displays  both
      values. It also displays a nifty diagram which can tell you  how  much  time
      was spent in method A due to calls by method B. This sort of information  is
      hard to convey in a tree structure. Optimizeit is also a good deal faster. I
      have, however, found it to be quite inaccurate; it's only good for getting a
      rough idea of where the bottlenecks are.
12. Speed!
      [Answer] [eclipse.tools]

      Subject: Re: [ANN] Eclipse profiler plugin, 0.5.3
      From: [e-mail] (VJ)
      Newsgroups: eclipse.tools
      Organization: EclipseCorner
      Date: Jan 28 2003 14:17:05

      "Konstantin Scheglov" <[e-mail]> wrote in message
      news:b15190$5fr$[e-mail]...
      > VJ wrote:
      >
      > > >   May be it reads from disk? Or swapping?
      > > No, I have almost 1GB of RAM.
      >   Wow, I only 128Mb.

      Hmm. Maybe I should send some to you....I have more than I need.

      > > > methods, overhead can be very big, up to 100 times.
      > > Thanks; excluding library packages does speed it up a lot.
      >   Good.
      >
      > > Verified that this works. Thanks.
      >   Good.
      >
      > > A suggestion for the future: The Time column in the methods tab seems to
      > > measure how much time was spent in that method itself. It would be
      useful to
      > > also have the ability to see how much time was spent in a method and all
      > > methods that were called by this method. Borland's Optimizeit displays
      both
      >   Ok, this is fairly easy.

      It'd be great if you could do this. This would allow high level
      optimizations instead of just low level.
      This is the main feature I need that'd make me switch from Optimizeit to
      your plugin.

      > > values. It also displays a nifty diagram which can tell you how much
      time
      > > was spent in method A due to calls by method B. This sort of information
      is

      >   Do you have example of such diagram? Can you give me screenshot? I saw
      > some diagram in WSAD, but personally I understand nothing from it. :-)

      I could send you the screenshots but it'd probably be easier for you to
      download a trial version of Optimizeit 5 from
      http://www.borland.com/products/downloads/download_optimizeit.html and look
      at it yourself. They give you a 5 day trial license, but you can just get a
      new trial license when your old one expires. If you'd rather have
      screenshots, let me know and I'll mail them to you.

      > > hard to convey in a tree structure. Optimizeit is also a good deal
      faster. I
      > > have, however, found it to be quite inaccurate; it's only good for
      getting a
      > > rough idea of where the bottlenecks are.
      >   Hm...
      >   What version of OptimizeIt do you use? I use 4.11, on my test it works
      > approximately with same speed as my profiler.
      >   I have one idea, something like "sampled instrumentation", it can really
      > increase speed, but decrease accuracy.

      It's common for Optimizeit's figures to be off by a factor of 2 or 3. I just
      compared the figures given by the profiler and optimizeit. The profiler
      seems to give unduly high times to small methods that get called very often
      (at least in comparison to Optimizeit). Perhaps this is an instrumentation
      overhead not being allowed for completely? For example a tiny getter method
      that just returns a string is shown as consuming 5.97% of run time by the
      profiler and just 0.34% by Optimizeit. The method is called 5.3 million
      times. I'm inclined to think that the optimizeit figure is closer to the
      truth.

      I put the getter method in a loop and ran it 50 million times and calculated
      the run time per iteration. it came out to be 0.00000000902 seconds. This
      includes the looping overhead. The profiler, however shows a time of about
      0.0026 seconds per invocation. This test was probably flawed, though as the
      compiler probably optimized the loop structure so as not to call the same
      getter over and over since its value didnt change...9 nanoseconds per call
      is way too low to be true. Perhaps I'll write a better test when I have the
      time.

      I use Optimizeit version 5. I just did a side by side comparison. Optimizeit
      took 63 seconds where your plugin took 360 seconds. On looking closer, I see
      that the profiler runs at a good speed for some time but freezes in the
      middle of the execution for several minutes and then starts executing at
      high speed again. You might want to look into it. I'm afraid I cant send you
      the test program on which the problem occurred, so you may not be able to
      easily reproduce the problem.

      I'm using a simulation algorithm as the test program. The above freezing
      problem was occuring after the fifth iteration of the simulation. I reduced
      the simulation iteration count down from 10 to 5 and ran the speed
      comparison again. This time there was no freezing. Optimizeit took 23
      seconds versus 61 seconds for the profiler.

      Optimizeit doesnt display timings while profiling like you do. It displays
      them after the profiling is complete. reducing the refresh rate didnt have
      any appreciable effect on the profiler speed though.
      Thanks
13. VerifyError
      Sorry, I do not understand. :(

      I am trying to profile jboss 2.4.7-jetty 4.0.4

      The error I am getting is:

      [INFO,ContainerFactory]
      Deploying:file:/E:/JBoss-2.4.7_Jetty-4.0.4/jboss/tmp/deploy/Default/exponlin
      e.ear
      [ERROR,Proxies] unexpected error
      java.lang.VerifyError: (class: org/jboss/web/WebServiceMBean$Proxy, method:
      getTargetTypes signature: ()[Ljava/lang/Class;) Inconsistent stack height 1
      != 2
       at java.lang.Class.getDeclaredFields0(Native Method)
       at java.lang.Class.privateGetDeclaredFields(Class.java:1494)
       at java.lang.Class.privateGetPublicFields(Class.java:1526)
       at java.lang.Class.getField0(Class.java:1725)
       at java.lang.Class.getField(Class.java:900)
       at
      org.jboss.proxy.ProxyCompiler$Runtime.makeProxyType(ProxyCompiler.java:164)
       at org.jboss.proxy.ProxyCompiler.<init>(ProxyCompiler.java:25)
       at org.jboss.proxy.Proxies$Impl.makeProxyConstructor(Proxies.java:675)
       at org.jboss.proxy.Proxies$Impl.newTarget(Proxies.java:550)
       at org.jboss.proxy.Proxies.newTarget(Proxies.java:51)
       at org.jboss.proxy.Proxy.newProxyInstance(Proxy.java:33)
       at org.jboss.util.MBeanProxy.create(MBeanProxy.java:39)
       at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:365)
       at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:307)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at
      sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
      )
       at
      sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
      ..java:25)

      Rgds
      Ved