Performance Zone is brought to you in partnership with:

Prashant is the Oz behind Chronon. Inspired and frustrated by years of breakpoint guesswork in the current debuggers and fumbling with printin() statements and logging frameworks, Prashant set out to find a different way to debug programs. Chronon is the result of his efforts. Prashant has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

Choosing what to record - Part 1: Controlling Performance

  • submit to reddit

Consider this line of code which reads in the contents of a file.

byte[] contents = readFile(fileName);

The method readFile() in this case could belong to some third party library, the JDK or may even be a system call. 

As far as debugging our application is concerned, we are not worried about what happens inside this method. And that is because we never wrote it in the first place. It is entirely possible that we may not even have the source code to this method. The only thing we care about when we debug our program is what the arguments and return value to this method were, which in this case would be the file name and the returned byte array.

Thus the central observation being -

  1. You cannot debug what you/your company didn't write.
  2. Even if you could, you probably cannot change the faulty code because it is controlled by third parties.

We utilize this observation inside the Chronon recorder to achieve performance. The recorder is designed to record only the code of 'your' program.  For calls to all methods that reside in a third party library, or the JDK or native method calls, we only record the arguments and return values of those methods, since that is all that is needed to debug your program.

Download this gallery (ZIP, null KB)Download full size (14 KB)

This also allows you to control the exact impact the recorder has on the performance of your program. Thus for example you may have a million line J2EE application but it spends most of its time waiting for the database or inside third party libraries or webservers. In this case the performance impact of the recorder will be extremely low since the time spent in 'recorded code' is very low.  This is also the reason why most web apps can get away with using platforms like ruby, python or php, all of which are much slower than java, because the time spent in that piece of code is very little.

On the other hand, you can have a 20 line program where all its does it do some massive calculation in a tight loop. In this case almost all the time is spent in recorded code thus having a much larger impact on performance.

Of course since this is the first version of Chronon and not meant for deployment in heavy duty 24x7 production scenarios the latter case of performance impact is not such a huge problem. That said we do have plans to dramatically decrease the performance impact from recording in upcoming releases without the need to exclude code from recording.

In the next few posts I will describe how to tell Chronon what to and what not to record and the consequences of excluding code from recording when using the debugger.



Published at DZone with permission of its author, Prashant Deva.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Matt Avery replied on Tue, 2011/03/29 - 6:27am

This looks pretty cool.  I think my open source project is complimentary.  Not the same approach, but people who find Chronon interesting will probably also find the Java Test Object Recorder interesting as well.  Downloading the free beta of Chronon now...

Sura Sos replied on Tue, 2011/03/29 - 8:23am

You should also test third party code. Replace it with other if it is performing badly. Simple as that. Ruby and php codes can be performant and scalable. Search for real world application written in that language (use google)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.