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.

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.