$ thought | blog

This is another new discussion topic in Java circle. To get the background for this post you would like this good article. This post has some great comments so don't miss that either. Followed by this and this article. There are different opinions about the topic. I studied Parallel computing & architecture as my graduate studies. So I would like to poke my nose in this topic.

This discussion is circling around GC threads and JavaEE threading model. Although experienced bloggers have already touch length and breadth of the topic, I would like to express my view in this regard. Operating system designers and architects thought a lot about Uniprocessor and Multiprocessor execution methods. There is huge literature present on these topics on public sources. But multicore techniques are relatively new.

Java scales very well on multi-processor servers from long time. Since multi-core is similar to multiprocessor in great sense, there should be increase in performance. Although as Billy mentioned there is GC bottleneck but, that is something can be worked out through JVM only. If JVM can utilize different processor for GC then why not different core?

In addition to that, there are very sophisticated parallel computing algorithms and utilities which may increase the performance by re-writing the existing application or designing new applications to work better on multi-core architectures.

This problem can be worked out and not impossible. If Java is having problem so do all the other monolithic applications which were designed by keeping in mind uniprocessor / unicore architectures.

And there is always option to use libraries like Pervasive Datarush and Javolution to increase application performance without bothering about details of architectures

Update (22/May/2007): I have also included Groovy performance as per Tom's comment. The post is here.

Recently I got a requirement to provide scripting capabilities in our product. A while ago, I was reading about JSR 223 and thought to have hands on the scripting capabilities of Java. While searching Internet I came across a page which states number of programming languages for Java VM. The most appealing options for me were Rhino, BeanShell and JudoScript. Ofcourse Groovy, Ruby and others are good too, but I wanted a simple and close to Java scripting for my product.

To get a quick start, I chose Rhino and BeanShell. JudoScript sounded like lots of in-built capabilities and since I didn’t want a Swiss-knife kind of thing with me so I chose to go with generic approach of Rhino and BeanShell.

In our case, developers will write some small routines to process sql resultsets. Typically the operations will be getting values in different columns or creation of sets etc. So my job is to provide a framework which takes sql queries dynamically and pass on the resultset to script. Script will process resultset and return the Lists or HashMap to framework again so that further processing can be done. So from my perspective resultset processing abilities was a winning point. For those who are more interested in computational performance analysis, I hope they will love to see this page.

Coming back to data processing capabilities, I set a simple test case with following steps:

• Get Resultset
• Note start time
• Process Resultset using Java / Rhino / Beanshell code.
• Note end time

I kept number of records as a variable in all of the executions. Thus I wanted to see the effect of increasing recordset size on performance. I started with 50 records and final reading was taken at 50000 records. Result of tests is as follows -

To help you understand clear the tabular representation of above data is -

On your machine the figures may vary a little bit but the ratio should be roughly same. BeanShell's performance is dropped suddenly with the larger size of record set. On the other hand Rhino performs consistently and balances better with the size record set. For Java the ratio for 50:50000 records is 1:37 but for Rhino its 1:15. For Beanshell same ratio stands as 1:45! This clearly shows that there is consistency in performance of Rhino compared to BeanShell.

Although Rhino is winner from the performance perspective, I need to admit Beanshell is homely for Java developers. The communication between beanshell and java is almost seamless. For Rhino you need to understand Scope, context and little more Rhino specific things but for BeanShell there is no complexity. So from simplicity perspective I vote for BeanShell.

My advice to others will be, there is not much difference in both of the scripting engines. Normally neither we process (or at least not supposed to process) 100000 element sized lists nor so big datasets. So its mere matter of choice for majority of users. Go with BeanShell if your end-user is a Java Developer as its very easy to understand the operation and there is very little learning curve.

If you like JavaScript or needs millisecond accurate performance guarantee then choose Rhino as it proves to be consistent. I didn't get chance to test E4x and other features but overall Ecmascript 4 is good. I will love to hear any other experiences regarding above two or any new engines.