What's good and what's bad about profiling nowadays

4. IDE integration

Tools should be integrated; otherwise it's not easy to work with them. Developer's tools should be integrated into developer's IDE.

What kind of tasks can the profiler's IDE integration provide? Basically, there are two:

[open in new window] Figure 1.
  • launching profiled program from the IDE with minimal, or better yet, no inconvenience
  • providing easy access to the source code of the profiled application from profiling results
1. It is logical to seamlessly incorporate profiler-specific commands and settings into the native IDE user interface:
a) The Profile action is convenient to add to the IDE menu, so that it can be called like any other command. For example, in IntelliJ IDEA YourKit adds the Profile action where similar Run and Debug actions are allocated (namely under the main Run menu, in context menus, on the toolbar):
Figure 2 [open in new window] Figure 2. b) Additional profiler-specific settings should be incorporated into the IDE Run Settings, as it is, for example, done in the IntelliJ IDEA integration:
Figure 3 [open in new window] Figure 3. c) The output console should not be different from the ones provided by the IDE. It should look familiar, in order not to produce any confusion. Taking IntelliJ IDEA integration as an example, we can see that the profiler console is absolutely the same as that used by Run and Debug commands, as it looks and behaves the same way:
Figure 4
[open in new window]
Figure 4.
2. Many profilers still have code access problems, as they can open the source code only in their own editors, which is not convenient at all. The first thing that crosses one's mind when talking about quality integration, is the ability to view the source code (coming from profiling results) exactly where one usually works with code, i.e. in the native IDE editor. At the same time, there should be some dedicated standalone UI for analyzing profiling information, specifically designed for convenient output. The last two statements may sound mutually exclusive, but when this theory is turned into reality, it becomes simply the right tool:

So, these were the two major issues. And there are obviously more requirements for a good profiling tool.

Having summarized the above, I would say that the following main features define an integrated profiler that covers the most important developer needs:

  • quick and transparent setup process
  • support for the most popular IDEs (e.g. IntelliJ IDEA, Eclipse, or Borland JBuilder)
  • use of IDE-specific UI, possibly along with own standalone UI
  • one-click ability (with devoted shortcut) to launch the profiled application from an IDE
  • use of the native IDE editor for showing the source code from profiling results

The only question that might still remain concerns the use of the standalone UI. This is, in some sense, a matter of preferences, and many developers would prefer inlined views. This is the feature we are already working on, to provide this option for the YourKit users who do not want to leave their IDE at all.

5. Usability

Feature sets of same-purposed products are often similar. But products are not equally easy and comfortable to use. Details make the difference.

The usability aspect in a profiling tool is worth mentioning. There are several main usability drawbacks that are often met in different profilers:

  • Many existing profilers are mouse-centric, while keyboard is the main working device of a developer. Vendors of big IDEs, having analyzed why many developers still prefer text editors, have started applying the keyboard-centric approach in their products. The same is topical for other everyday tools that developers work with, and profilers are no exception.
  • Working with regular profilers, a user is forced to once again configure the existing project parameters, like directories for compiled classes, sources, or jars used. Is it really a good idea to make a profiler a kind of "launching center" for the profiled application? It seems much easier to add a very small profiler-enabling stuff to the existing configuration, rather than make a user repeat all project configuration steps again, just for the profiler. This can be achieved by just adding one parameter to the application/project.
  • An inconvenience is also met in profilers that open the "problem code" in their own windows, while it is obvious that the ability to work on code in the preferred environment is what a developer would prefer. Opening the "native" IDE editor would provide access to all the advanced IDE features, which would make the fixing process really user-friendly.
  • When it comes to manual configuration for profiling an application (for whatever reason), specifying correctly all the necessary parameters takes much time and is not always an obvious procedure. For example, setting bootclasspath, to enable profiling in an application directly, can sometimes be a rather painful and error-prone task. Why not making things easier, like by just adding the application command line parameter that would point to the profiler agent library?

Having analyzed the existing drawbacks and possible ways to get rid of them, we realized that applying these solutions would definitely brighten the life of those developers who value usability and comfort in their daily work.

All of these usability improvements, as well as many others, are already implemented in YourKit. And there are more to come.

These were just a few thoughts of mine. If you want to discuss them, you are welcome to our forums (http://forums.yourkit.com)


http://www.yourkit.comYourKit Java Profiler website
http://forums.yourkit.com YourKit users forums
Anton Katilin / YourKit
page 2 of 2