Sometimes your program executes slower than you expect. Of course the code we write ourselves is perfect and the bottleneck is hidden in one of the third-party libraries. It does not make our life easier, does it? What are the steps to investigate the root cause of the issue? What is the proper way to profile Java application?

Code profiling is not a mere launch of a profiler tool. On contrary, profiling is a process that enables you to catch performance bugs proactively during development phase, hunt them in test environment as well as in production. System.out/perf4j/poormansprofiler might perfectly suit for some cases. Those approaches, however would not help you with investigation of yesterdays slowness of QA server. How would you convince a customer to implement your profiler in production server taking into account the fact he might have previous negative experience with «profilers». Profiling process should not get in the way of typical development flow, so simple tasks like «find a method in the profiling result» should indeed be simple.

Java allows you create your own profiler in a blink of an eye: Instrumentation API enables you to augment java classes, and write-once-debug-everywehere bytecode allows to support different hardware platforms without pain. We will review how those features could be used to write a profiler. We’ll see why certain profilers might not meet requirements/expectations of your cusomter. We’ll higlight the key points for creating a profiler from scratch, and discuss how profiler should interact with the application being profiled.