« Create a DevExpress NavBarGroup with a CheckEdit in its header | Main | Code Wars – prepare to fire a broadside mateys! »

06/03/2011

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a0115711bf0ae970b01538eecddff970b

Listed below are links to weblogs that reference The Lazy Man’s Profiler:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

"Record where you are in the program?" You mean just eyeball where you are and make a mental note of it? Every 10 seconds? And just hope you land on a piece of code that's a bottleneck? This sounds like a very crude approach.

Could you perhaps give an example of how you've successfully tuned code like this while writing Enterprise-grade software?

Hi RobotDadcat;

I can give you a good recent example. We have a customer who ran under a profiler and found that ExecuteSelect() was taking all the time. They were next going to set up a profiler in Sql Server when I suggested this approach.

They did 10 breaks and found each time it was for the same select - which had a condition on a column that was not indexed. They indexed the column and it then ran super-fast. So a minute of hitting break instead of configuring Sql Server to profile incoming selects.

As I said in my post, it's not always the best approach. But it works well in many cases. And when it does, it saves a lot of time.

I also use this all the time. A recent example (for RobotDadcat) was a report running very slowly on a piece of third party software (financial reporting software that cost well over $1M). I hit pause a few times and it was always stopping on the same piece of code that was loading simple data. I looked down the stack and it turns out that that the data was being loaded 25,000 (for each item in the system) but it should have been loaded only once at the start. Once this was removed the report run in under half the time.

This method is very good for discovering really stupid errors rather than subtle ones.

In the java world you can do the same even easier using ThreadDumps. Using the command jstack which is in the java bin path.

For example in a linux shell.

for i in `seq 0 10`;do jstack $PID_OF_JAVA_THAT_NEEDS_PROFILING;sleep 10s;done |less

And you can quickly see extreme hot spots.
However, once the worst problems are found you might want to break out the free jvisualvm and use the sampling profiler included for the less obvious performance problems.

As long as you're already connected with a debugger, why not set your breakpoints up so that they don't pause any threads and log very simple expressions. I've used this technique extensively to instrument "ad hoc logging" and to do entry/exit logging on key methods that I suspect/know are involved in the operation I'm investigating. The debuggers in all three major IDEs (IDEA, Eclipse, and NetBeans) support this feature.

Or you could use a light-weight sampling profiler like the one I built for MessAdmin, my open-source monitoring tool.

In addition to CPU profiling, you will also get tons of information on your application, including when you leave your dev box and go in production.

(Disclaimer: the CPU profiler is unreleased yet as of this writing. Send me an email should you want to have a copy before I release it to the world.)

The comments to this entry are closed.

David Thielen

B.I. Tweets

    follow me on Twitter

    Windward Reports

    Quantcast

    • Quantcast