Eclipse-based CodePro Profiler new version and flexible pricing

Discussions

News: Eclipse-based CodePro Profiler new version and flexible pricing

  1. Launched by Instantiations in 2007, CodePro Profiler™ was the first enterprise-ready performance analysis tool designed specifically for the Eclipse platform. CodePro Profiler’s automation helps Java Eclipse developers efficiently identify performance issues early in the development cycle. It's a run-time performance analysis tool that helps find CPU and algorithmic bottlenecks, memory leaks, threading issues, and other concurrency-related problems that can slow down an application or cause it to hang. CodePro Profiler's flexible subscription-based pricing was created to better fit the way you work -- with one-month and one-year subscriptions available, starting at $39, including support. Perpetual licenses are also available. You can deploy it on each developer’s desktop or integrate it into the build process and/or web/application server to receive highly accurate profiling with nearly zero overhead. It works with Eclipse, MyEclipse™, and IBM Rational®. Free trial available at http://www.instantiations.com/codepro/profiler/download-trial.html.

    Threaded Messages (8)

  2. excellent idea[ Go to top ]

    the pricing model where you can rent a profiler for a month or so is a fantastic idea. for instance, i tend to use a profiler intensively for a couple of weeks at various points of the iteration. i rarely touch it outside of that.
  3. Wonderful news[ Go to top ]

    Wonderful news, this is what we were looking for, just rent it for some time. This will really help us to negotiate with customer. Thanks, will try and evaluate. Thanks M.G.HEGDE
  4. ZeroLatency?[ Go to top ]

    Sorry to be the bearer of bad news but the "nearly zero overhead" claim is complete nonsense. Our performance analysis of your instrumentation shows the CodePro product to be 10x times slower than VisualVM's profiler on OS X with the BCI instrumentation flag checked. The code we used to test this is listed on our own benchmarking page below.
    Note: Our OpenCore resource metering runtime is close to 30x times faster than VisualVM own profiler. Sub Zero?
    http://opencore.jinspired.com/?page_id=123 Are you talking about cpu sampling here because that is easy to configure to make it appear to look like close to "zero overhead" at least in a single thread test but in an enterprise context with double digit thread numbers this does not hold true unless of course your application is IO/DB bound. http://williamlouth.wordpress.com/2009/01/16/profiling-sampling-versus-execution-part-2/
  5. Re: ZeroLatency?[ Go to top ]

    Of course any kind of profiling introduces some overhead to the application. Such an overhead depends not only on profiler implementation but also scope of profiling, kind of application and kinds of information being collected. We are usually using CodePro profiler with the following schemes, which seems to be best for solving real-life performance problems: The first scheme that we are using is for ‘regular’ applications where most of the code is not computation-intensive. Step 0: Profiling application in the sampling mode. This allows determining major bottlenecks even if keeping a sampling frequency relatively low. Step 1: Configuring BCI filters to cover the major bottlenecks being determined on Step 0. Then optionally turning on “flat” mode to reduce overhead even more (in case when you do not need call graph data this helps quite a lot). Profiling application once again. This allows us keeping overhead relatively low and having quite a detailed snapshot of the area of interest. In case when we need to profile something computationally intensive, we are using “trigger” feature to limit a scope of profiling to exact area of interest. We did not compare CodePro Profiler to VisualVM’s profiler or to OpenCore actually but we tested it against YourKit and JProfiler on various Eclipse plugins and also on SpecJVM scenario and found it performance being better. For SpecJVM case all profilers have significant overhead in BCI mode, but for Eclipse in most scenarios that we tested overhead of CodePro profiler was quite acceptable for us. By the way the code in your sample looks to be quite different from a code of an average J2SE/J2EE application. I see too much of exceptions being thrown, very few traces etc. According to my opinion Eclipse (~20 threads, average call stack ~60) is a better benchmark due to it being a real-life application. Regards, Pavel
  6. Re: ZeroLatency?[ Go to top ]

    Pavel, I think you missed the whole point of the example. The example is trying to accurately measure the overhead per method for each profiling solution. It is not trying to representative of an application but to determine what is the cost for each method instrumented bear in mind that filters cannot exclude all those lightweight methods that executed very frequently in an reasonable size application. You overhead per method instrumented is above 6 microseconds. This is extremely highly and I doubt your SPECjvm2008 figures could look in anyway reasonable with such an overhead considering that most benchmarks are highly CPU intensive executed millions (billions in some cases) of method calls per test cycle. William
  7. Re: ZeroLatency?[ Go to top ]

    No exceptions are thrown during the benchmark. The code has been deliberately written this way to thwart some VM and profiling optimizations.
  8. Re: ZeroLatency?[ Go to top ]

    Hi William, as a specialist in performance optimization area you know that instrumentation overhead per method depends from a lot of factors and may vary very significant depending on application.
    filters cannot exclude all those lightweight methods that executed very frequently in an >reasonable size application.
    CodePro has a special option – skip simple methods, which allow excluding simple methods from instrumentation scope automatically.
    You overhead per method instrumented is above 6 microseconds.
    According to our measurements CodePro Profiler overhead per method is ~1.4 microseconds in average(0.6 microsecond on timing, and 0.8 on other stuff) and this does not look too high (at least in my opinion) for a solution which gathers complete call graph of a profiled application.
    This is extremely highly and I doubt your SPECjvm2008 figures could look in anyway >reasonable with such an overhead considering that most benchmarks are highly CPU intensive >executed millions (billions in some cases) of method calls per test cycle.
    As I mentioned before, initially SPECjvm2008 should be profiled with sampling, and only then BCI instrumentation should be used. Also you may look on: http://download.instantiations.com/ProfilerDoc/continuous/latest/docs/html/whatsnew/whatsnew_1.6.html to see the comparison of CodePro instrumentation performance with other profiling tools. By the way, we have checked the features provided by JXInside probe and it seems that your idea of dynamic instrumentation and low overhead probes are quite useful for a case when scope of instrumentation may not be limited by some reason, so I really hope to see the same feature in the upcoming CodePro Profiler release. Regards, Pavel
  9. Looks great, I did a trial then thought about a year would be nice so got the year sub. But the Serial didn't open the plugin. Support told me to use the serial, and or the key, which I did of course. So you can buy it but you can't use it. Hmmm.... I need a business model like that. Pity. Michael