As we get all set to release Chronon 3, we noticed that some elements of our website were causing confusing among our visitors, thus we decided to update it. Below is the description of what we changed and why we did so.

What has changed

The changes we made really boil down to the 2 most visited links on the header menu of the website: 'Pricing' and 'Download'.

The change we have made is that we have removed those links from the header menu.

Why remove links from the header menu?

Now, you are probably thinking why would we remove what are probably the most visited and important pages of the website!?

Well, first of, rest assured, the pages still do exist, they have just been moved around to a more appropriate location. Details are as follows:

As it turns out, when we launched last year with our first product, the Chronon Time Travelling Debugger, we were a single product company, so it made sense to have a single pricing page and a single download page. It caused no confusion whatsoever for the visitors since they got exactly what they were looking for.

However, fast forward to now, we have multiple products, 3 in fact:

1. Chronon Time Travelling Debugger
2. Chronon Recording Server
3. Embedded Chronon

We even branded the 'solution' we offer as a combination of these products as 'DVR for Java' and came up with a brand new redesign and look and feel of the website in October 2011.

As it turns out, the redesign was an evolution of the structure of the previous website. Thus, although it had a 'Products' menu, allowing you to view each product, it still had a single 'Pricing' and 'Download' page. And this led to a ton of confusion for the visitors.

Confusions Abound

For example, here is the previous 'Download' page:

As you can see it contains downloads for both the Recording Server and the Time Travelling Debugger.

However, a lot of visitors to the site who came because they heard of the the Time Travelling Debugger, when they clicked the Download link, and saw a download button for the Recording Server, it got them utterly confused.

In fact, we received so many support mails on that, that we actually had to put a section on the side which literally said 'What is the Chronon Recording Server', along with the links to the Product Overview page to explain that we have multiple products.

A clickmap of the download page showed that these links were indeed being visited by a lot of users and thus provided us with more evidence that there was a ton of confusion.

In the pricing page, we tried to solve this problem by tabs and having different tabs for each product.

Again this was not a perfect solution since, the tabs were not all that eye catching and still didnt give the user an instant feedback that there are multiple products involved.

The new changes

So to simplify things, we have removed the single page 'Download' and 'Pricing' from the top menu bar and placed 'Download' and 'Buy' buttons on the pages of each product.

This way there is no confusion, if you are on the Time Travelling Debugger product page and click on the 'Download' or 'Buy' button, you don't see the Recording Server. Same with the Recording Server buttons.

 Also since you probably got to the Recording Server page, by clicking on the 'Products' menu item, you know that multiple products are involved.

We hope this change will simplify things a lot for our visitors.

More to come....

We are still working on making continuous improvements to the website as we go along and in the spirit of the 'Engineering Chronon' blog, we will keep you informed of the changes and the rational behind those changes.

Do you press the 'Stop Recording' button each time your app runs into a bug and you want to examine the recording? Or do you press it once your test suites have finished running?

Turns out, that is not the way we designed the Recording Server in mind!

Recording Server Workflow

Here is a document describing the workflow of using the Chronon Recording Server:

http://chronon.onconfluence.com/display/DOC/Recording+Server+Workflow

We have just released the first update to the Chronon 3 beta.

Recorder Binary version number: 3.138 

This update contains:

1. Fix for linux users who were crashing with the following error msg: 

/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found 

You shouldn't be seeing this anymore.

2. New much faster, 'low' compression option!

In the Recorder Configuration file, you can add a property to use the new, much faster compression algorithm:

compression = low

More specifically, previously we used Deflate for compression, but using compression=low in the config file will use Snappy which is an order of magnitude faster albeit with a lower compression ratio.

Note that this configuration option in the configuration text file is only temporary during the beta. Once Chronon 3 is released, you will be able to control this setting through the Recording Server UI.

Also some clarifications...

Apparently some of the earlier mails sent out said that 'Chronon Recording Server 3' is available for download. That is incorrect.

The Recording Server is still at version 2 and its binaries haven't changed. Chronon 3 currently just consists of the recorder binaries and you just need to copy/paste them in your existing Recording Server (v 2) installation to use them.

Our apologies for the faulty mail. 

Download now

If you haven't already got Chronon, fill this form to get it instantly!

 

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 fair chunk of change on KickStarter.

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 needs 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?

Conclusion

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.

 

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

 

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 chrononsystems.com 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 .

Chronon won the award for Best Developer Tool at EclipseCon 2012. Combining last year's Hot New Product victory, thats 2 wins in a row for Chronon at EclipseCon!

Thank you everyone for supporting us!

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.

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)

Remedy

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.

Benchmark

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:

Conclusion

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

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.

Benchmark

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

Conclusion

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.