Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Boost Efficiency with a Performance-tuned Debugging Strategy-2 : Page 2


advertisement

Common Debugging Techniques
Virtually every serious java application is going to have at least one, and probably multiple try/catch blocks (if for no other reason than that the compiler forces you to catch certain potential behaviors). Although exception handling can be a useful way to deal with runtime errors, it is generally not sophisticated enough to identify what went wrong in the code to produce the erroneous data that threw the exception. How many times have you received the infamous "NullPointerException" and gone to the portion of the code in question and thrown up your hands because there's no way to tell which exact piece of code threw the exception. Even if you knew exactly where the null reference occurred, how did it come to have a null value? At what point did it cease to have a valid value? Was it earlier in the method, was it null before the reference entered the method, is the value in the database null?

After this frustrating scenario occurred several more times, you no doubt decided to develop a consistent debugging framework to maximize your development time and increase efficiency. Perhaps it was as simple as reporting key variable values and application-level events by sending them to a log file. This is a good solution. When an error occurs or an exception is thrown, often you can trace back through the log to the first time that a reference or value was assigned to the offending variable. You are now able to track down in a few minutes, an error that used to take an hour to find before you began logging system activity.

This technique has successfully increased your efficiency. Unfortunately, your code's efficiency is very likely suffering.



Cutting Out the Fat
Most debugging techniques are inefficient and degrade code performance. This is fine for development but unacceptable for production-quality code. Consider the following example:

logIt( "Entering while loop" );
while ( x < y )
{
	logIt( "Inside while loop" );
	x*=5;
	logIt( "x is equal to " + x );
} // end while( x < y )
logIt( "Exited while loop" );

private void logIt( String message )
{
 //write to log file
} //end logIt()

This will produce very useful debugging information. The problem is that if you do this across your entire application, then the bulk of your system processing will become the creation of and garbage collection of String objects (not to mention the I/O processing occurring within the "logIt()" method). This is particularly crucial when we move this code into production!

What's the solution to this? Many developers come to the conclusion that we simply need to be able to turn debugging off for production. Often, this is done by creating a boolean primitive that is set to "false" for production. Then this member is evaluated in the logging method. For example:

private void logIt( String message )
{
	if ( getDebug() == true )
		// write to log file
}

Great! So we've managed to eliminate the unnecessary I/O processes, but what about all the calls to this method? The code is still littered with String objects that are created, and garbage collected regardless of whether or not debugging is turned on, not to mention the overhead from method calls to a method that doesn't do anything. It may seem like I'm making a big deal over nothing, but do not underestimate the effect that object creation and garbage collection have upon the performance of your code.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date