Posted September 03, 2010
To Profile or Not to Profile – That is No Longer the Question
By Sergei Sokolov
Director of Product Management
Test and Performance Solutions
In today’s software development industry, few doubt the usefulness of code profilers and runtime debuggers – these are tools that save hours, and sometimes, weeks of engineering effort to track down tricky performance and memory bugs, or establish required code coverage. In fact, a code profiler is accepted as one of the essentials in the Agile team toolbox – and those teams are anything but hung up on using tools for tools’ sake. So, we are proud to provide you, the user, with the latest version of AQtime, AQtime 7.0, which has just been released – expanding profiling support to Visual Studio 2010, Embarcadero RAD Studio XE, and – finally – Java.
The question that is still a matter of professional preference is WHEN to profile. There are clearly two distinct positions here. Some use the profiler as a fire extinguisher – waiting until the application starts to crawl after a bunch of code check-ins, or gobbles up memory like PAC -MAN, before investigating what is going on. The good news is – automated tools like AQtime will help you find what’s wrong with code much faster than manual inspection, custom debugging, or deductive reasoning. The not so good news is that a bug is a bug, and the longer you wait to discover it, the more time and effort it takes to fix it.
Personally, I have preferred far more to use profilers as the code is written. Granted, some amount of code and tests need to exist so that it can be run – either unit test harnesses, or a prior version of the application. Yet, being able to detect problems rapidly as they show up after code changes is a much more efficient approach to produce and maintain clean code, and generally pays back many-fold on effort to create and maintain an appropriate test infrastructure
Please share your experiences with us – whether you use AQtime or other similar tools in a continuous integration setup, or prefer a “lazy” approach – show me the bug, then I’ll fix it! Happy profiling, either way.