Light Table: Concept vs Reality

Posted by Prashant Deva on April 22, 2012

I recently came across this ‘concept demo’ of Light Table, which is being passed off as a ground breaking IDE, and has even managed to collect a <a href=””>fair chunk of change on KickStarter</a>.

Being the geek that I am, it piqued my interest too and I took a good look at it. After analyzing the demo, even though the video looks cool, I dont see most of the functionality as groundbreaking and large parts of the demo seem highly contrived. Here are my thoughts and critique on what the Light Table concept demo.

Since I am a Java guy and the IDE concepts are defined as being language agnostic and that support for additional languages can be added later, I will compare the examples using Java code and Eclipse as the IDE.

Let’s look at Light Table, feature by feature.

Docs everywhere


Here the author demos putting cursor on top of method calls and showing documentation on the side. He tries to pass this off as something revolutionary.

Maybe he should just open eclipse and its javadoc view, which does exactly the same thing.

Also unlike what is shown in the light table demo, where the documentation panel eats up half your screen, the javadoc view can be easily docked to any size and resized to preference.

Also the author says ‘docs everywhere’, but the demo shows that there is a special ‘doc’ tab you have to click on to be able to see the documentation (since it eats up half the screen). That means the ‘doc’ is in fact not everywhere and you have to switch to a special ‘documentation mode’ to see it.

Contrast that to eclipse’s javadoc view, which can stay open continuously whenever you want and can be docked and resized wherever you want.

Finding functions


I am assuming java here, so i will refer to classes instead of functions for my examples. Even though java does allow functions inside classes i barely ever find myself searching for anything by its function name. Its almost always a class name, especially since multiple classes can contain a function with the same name. Also just looking at pure functions usually doesn’t do it for me when examining code, since I also like to see the fields of a class.

Again what the author passes here for revolutionary is a trivial functionality in most IDE’s. In eclipse, you can press Ctrl+Shift+T and type the name of a class, along with wildcards or package names if you want and voila you can get to it instantly. Only this has been possible for about 10 years now…..

No dealing with files

Throughout the demo, it is emphasized that the concept of files is hidden from the user. While good in concept, this is at best a leaky abstraction. At some point you will have to deal with files since that is what your version control system works with. However, almost all ides including visual studio, eclipse and intellij can show you views of your code that contains only the structural elements and not the files. Sure when you go to ‘edit’ the code, it shows you file name in the tab above, but is that really such a big deal….


The demo shows nice little functions calls which have their own small editing area. This seems very contrived. The functions shown are extremely small. How would the editing areas look like if the function in question was long. Wouldnt showing multiple functions on a single surface then lead to a ‘resizing hell’, where you are constantly trying to resize the individual editor windows to see the code you want to see? Sure one can make the argument that you should have small functions, but real world code doesn’t exactly always play by those guidelines.

There is a reason why current ides only allow a split view of editors, and that is to avoid the ‘resize hell’ mentioned above since you only need to resize on one axis at most.

Instant feedback


In this part, which again feels extremely contrived, the author very conveniently shows small functions which operate only on primitive numeral types.

However, real world code rarely works that way. You have objects calling other objects which in turn can call apis which in turn interact with external systems.

How would the instant feedback work on a piece of code that deletes a bunch of files or sends a bunch of emails or is part of a distributed system and n

eeds some input from a network or is complex multithreaded code? I dont want files on my system deleted as soon as I type an api call in the ide, same with sending emails, etc.

The second image here shows a portion of the Chronon Time Travelling Debugger code. How would ‘instant feedback’ work in this case? The code here relies not only on the state of the program in memory but also takes as input external files present on the filesystem. Will Light Table somehow magically generate the files in question and in the proper format that this function expects?

Even if LightTable were somehow to ignore api calls that say, modify your filesystem, how would the IDE ‘know’ about that api. Will someone have to manually go through all the apis in existence and make a list of which ones to emulate and which ones to not? That doesn’t seem practical.

Also even if the code were indeed based on just basic numerical or string primitives, how would the ‘instant feedback’ work if the code were in a long, tight loop or did heavy cpu intensive stuff?


Even though the light table demo looks interesting at first glance, digging deep into it, some of the concepts presented as game changing like ‘documentation everywhere’ and ‘find function’ are already well implemented in other IDEs.

The other half of the demo looks extremely contrived and might look good in a ‘concept’ demo but the examples shown dont seem representative of real world coding and there is no solid explanation of how these problems would be tackled in the final implementation.

Chronon 2.3 released

Posted by Prashant Deva on April 11, 2012

Bugfix release for the Recording Server UI.
This is a bit of a late announcement since the binaries have been available since middle of last week.

If you are using v 2.x of Recording Server, then you can just update the .war file to get the new fixes.

You should no longer see screens like this anymore with v 2.3



Get it now:



Chronon Free for Open Source Projects

Posted by Prashant Deva on April 4, 2012

Last week we won the Eclipse Community Awards for Best Developer Tool. Guess its time we start giving back to the community too.

Thus today we are announcing the long awaited, free open source license program for Chronon!
Read on for more details:

What we are offering

Free licenses of :

  1. Chronon Time Travelling Debugger
  2. Embedded Chronon

Who can get it

There is the obvious requirement of having an Open Source project with an active community
Please don’t just check in a couple of files in github and ask for a free license. 

Apart from that we also ask for the following once your license is approved:

Allow submitting Chronon recordings to your bug repository

That’s it! Just allow users to post Chronon Recordings in your bug repository (as attachments).

This is a benefit to both you and your users:

  1. Your users can easily report bugs as a Chronon Recording instead of trying to figure out and report the exact steps to reproduce the bugs.
  2. You get to fix bugs more easily by just playing back the recordings using the free Chronon Debugger license.
  3. Users can report bugs that occur sporadically or would require a complicated setup on your part to report it. Currently these kind of bugs remain unresolved, but with Chronon that would no longer be the case.

You will need to mention somewhere prominent on either your support/contact page and/or bug tracker that you allow Chronon Recordings.

We will help you with the wording and placement of the text. We will even send you a small badge you can put on your website and link to a page on that will describe to new users what Chronon is and how they can benefit from using it with your project.

For Embedded Chronon licensees

If your open source project has a user facing UI, ie for example its a rich client application or an eclipse plugin, you can use Embedded Chronon and its APIs to add a ‘Record’ button inside your application!

This way, if your user wants to report a bug, but you dont want to have Chronon running all the time in your application:

  1. They can click on a ‘Start Recording’ button to dynamically start the recorder in the running application.
  2. When the bug has occurred, they can click ‘Stop Recording’.
  3. Then they can send you the Chronon recording in your bug repository where you can then easily debug the issue.

Again, a win for both your project and your users!

When can you get it

The free licenses will be available with the release of Chronon 3, however you can start applying for them now.

We believe the performance improvements in Chronon 3 and the resulting small recording file sizes make it much more easy to record applications and share those recordings.

We suggest all interested parties to request the Chronon 3 beta to start trying it out on your projects today.

For those interested in trying the full stack right now, you can download the free 30 day evaluation of Chronon 2.

Where to Apply

Fill the form here to get in the queue for open source licenses right now. 

For more questions, either post a comment or contact [email protected].

Chronon 3 beta: 10x performance improvement

Posted by Prashant Deva on March 23, 2012

Chronon 3 is all about performance.

We have rewritten our Recorder from the ground up to gain an order of magnitude performance improvement! The basic architecture remains the same, but under the hood its an all new engine. We turned a Yugo into a Ferrari!

No more memory issues

The biggest complaint of all users of Chronon 1 and 2 has been high memory usage and OutOfMemory errors. With Chronon 3 our main goal was to get rid of this. And I am proud to say we have blown it out of the ballpark with this one!

Chronon 3 makes absolute minimal use of your Java heap. We have shifted most of our code to native. And this time we made sure that literally every single bit of memory usage is accounted for! This means that you no longer have to fiddle with -Xmx values.

Here is a graph showing memory usage for recording entire Eclipse (namespace org.eclipse.**) with Chronon 2 and Chronon 3 (size in megabytes):


Smaller Recording file size

The Recording file size of Chronon 3 should on avg be 90-95% smaller than that of Chronon 2.

Here is a comparison of recording file size for the startup of eclipse, recording the entire org.eclipse.** namespace (size in megabytes). Note that eclipse has a lengthy, cpu intensive startup so its a good stress test.


Increased Concurrency

Chronon 3 pulls out all the stops to make sure your applications retain all of their concurrency. Highly concurrent applications will instantly see a very noticeable huge performance boost.

Logless Data Center

With the high performance of Chronon 3, you can have the Chronon recorder running all the time. This means you can have for the first time a Logless Data Center!

Consider this, with Chronon on all the time, you no longer need log files or log statements cluttering up your code. If something breaks, just pull out the Chronon recording and put in Post Execution Logging statements wherever you want.

Getting your hands on the beta

To get the beta, please fill out the form here.

We are opening the beta so you test the performance of Chronon 3 on your applications.

Since this is still beta, the recordings made from the Chronon 3 recorder will not open in the Chronon Debugger for now. You will need to use the Chronon Recording Server to record your applications. The only change would be that you would replace the recorder.jar in your Recording Server installation from v2 to v3.

If your existing Recording Server evaluation has expired, dont worry, we will give you a new one.

We would request providing some contact info so we can be in touch with you throughout the beta.

Please provide either a phone number or a skype id , or anything else (put it in the comments section). If providing a phone number, dont forget putting the country code.

Any spam/incorrect entries will be discarded.

Hidden evils of Java’s boolean array (boolean[])

Posted by Prashant Deva on February 2, 2012

Consider this piece of code which allocates a boolean array of 100,00:

boolean[] array = new boolean[100000];

What should the size of this array be?

Considering that a boolean can just be either true or false, every element in the array only needs a single bit of space each. Thus, the size of our boolean array in bytes should be:


100,000/8 + (overhead of array object) = 12,500 bytes + (overhead of array object)

But there lies the hidden evil….

The Evil Inside

As it turns out, when you allocate a boolean array, Java uses an entire byte for each element in the boolean array!

Thus the size of the boolean array is in fact:

100,000 bytes + (overhead of array object)


So is there any way not to use the 7 extra bytes when you only need the 1 bit? Its here that the java.util.BitSet class comes to rescue.

The BitSet class does indeed use a single bit to represent a true/false boolean value. Its implementation uses an array of ‘long’ values, where each bit of the long value can be individually manipulated to set any position in the entire BitSet to true or false.

The BitSet implementation does add a bit of cpu overhead since it has to shift and or bits together to set the value of the bit in the correct position. Thus you need to weigh the cost of memory savings versus the extra cpu overhead when using this class.


As an example, here is a screenshot from the YourKit profiler, showing the memory used by a boolean array and a bitset object, both 100000 element long:


As can be be seen:

The boolean array takes:
100,000 + 16 (array overhead) = 100,016 bytes

The BitSet object only takes :


100,000 / 64 (size of long) = 1562.5 = 1563 long values after rounding
1563*8 + 16 (array overhead) = 12, 520 bytes

A few extra bytes are added for the BitSet object itself and the extra 2 fields that it contains.

To put things in perspective, here is a graph showing the space occupied by both for 100,000 elements:



As can be seen from the graph above, using the BitSet instead of a boolean[] can save you tons of memory at the cost of just a few extra cpu cycles

Hidden evils of Java’s String.split() and replace()

Posted by Prashant Deva on January 25, 2012

If you code in Java, you have inevitably used the String.split() and String.replace() (including replaceFirst() and replaceAll()) functions.

And why wouldn’t you? They are much more convenient than using the Java Regular Expressions API where you need to create a ‘Pattern‘ object, and possibly a ‘Matcher‘, and then call methods on those.

However, all convenience comes at a price!

The Evil Inside

In this case, the String.split() and String.replace*() methods (with the sole exception of String.replace(char, char) ) internally use the regular expression apis themselves, which can result in performance issues for your application.

Here is the String.split() method:

Notice that each call to String.split() creates and compiles a new Pattern object. The same is true for the String.replace() methods. This compiling of a pattern each time can cause performance issues in your program if you call the split() or replace() functions in a tight loop.


I tried a very simple test case to see how much the performance is affected.


The first case used String.split() a million times:

In the second case, I just changed the loop to use a precompiled Pattern object:

Benchmark Results

Here are the average results of 6 test runs:

Time taken with String.split() : 1600ms
Time taken with precompiled Pattern object: 1195 ms



Note that I used an extremely simple regular expression here which consists of just a single ‘space’ character and it resulted in > 25% decrease in performance.

A longer more complex expression would take longer to compile and thus make the loop containing the split() method even slower compared to its counterpart.

Lesson learned: It is good to know the internals of the APIs you use. Sometimes the convenience comes at the price of a hidden evil which may come to bite you when you are not looking.


Chronon 2.2 released

Posted by Prashant Deva on December 13, 2011

This is mainly a bugfix release for all components.

Some enhancements to the Debugger UI:

Import/Export available for ‘Post Execution Logging’ and ‘Timeline’ views


Servers tab now has ‘Record’ button in main toolbar


Recording Server

Bugfixes for all 3 components: recordingserver.war, controller and recorder.jar.

Each component in this release can be updated indepently.

Thus for example, if you dont want to update the controller on each box, you can just replace the recorder.jar files with the updated one and leave the rest still running.

If however you are updating from a beta version, you will need to update all 3 components at once.

Grab the latest version from our download page now!

Chronon Step-by-Step Tutorial

Posted by Prashant Deva on December 8, 2011

Still don’t think you are utilizing Chronon to its maximum potential?

We have released a Step-by-Step Chronon Tutorial, where you can download a sample eclipse project and have us walk you through debugging it using Chronon, explaining every single feature.

It takes less than 10 minutes to go through the entire tutorial and by the end you will become a master of Time Travel!

« Previous 1 2 3 4 5 6 7 8 9 10 11 Next »