Groovy performance

Question

Hi We are going to start a CRUD project. I have some experience using groovy and I think it is the right tool. My concern is about performance. How good is groovy compared to a java solution. It is estimated that we can have up to 100 simultaneosly users. We are going to use a MySql DB and a tomcat server.

Any comment or suggestion?

Thanks

Answer 1

Performance (in the context of web applications) is an aspect of your application and not of the framework/language you are using. Any discussion and comparison about method invocation speed, reflection speed and the amount of framework layers a call goes through is completely irrelevant. You are not implementing photoshop filters, fractals or a raytracer. You are implementing web based CRUD.

Your showstopper will most probably be inefficient database design, N+1 queries (in case you use ORM), full table scans etc.

To answer your question: use any modern language/web framework you feel more confident with and focus on correct architecture/design to solve the business problem at hand.

Answer 2

50 to 100 active users is not much of a traffic. As long as you have cached pages correctly, mysql queries are properly indexes, you should be ok.

Here is a site I am running in my basement in a $1000 server. It's written in Grails. Checkout performance yourself http://www.ewebhostguide.com

Caution: Sometimes Comcast connections are down and site may appear down. But that happens only for few minutes. Cons of running site in basement.

Answer 3

Thanks for the answers and advices. I like groovy. It might be some performance problems under some circumstances. Groovy++ might be a better choice. At his point I would prefer to give a chance to "spring roo" which has a huge overlapping with Groovy but you remain at java and NO roo.jar is added to your project. Therefore you are not paying any extra cost for using it. Moreover "roo" allows backward engineering and roundtrip engineering. Unfortunately the plug-in library is pretty small up to now.

Luis

Answer 4

I've recently gathered five negative votes (!) on an answer on Groovy performance; however, I think there should be, indeed, a need for objective facts. Personally, I think it's productive and fun to work with Groovy and Grails; nevertheless, there is a performance issue that needs to be addressed.

There are a number of benchmark comparisons on the web, including this one. You can never trust single benchmarks (and the cited one isn't even close to being scientific), but you'll get the idea.

Groovy strongly relies on runtime meta programming. Every object in Groovy (well, except Groovy scripts) extends from GroovyObject with its invokeMethod(..) method, for example. Every time you call a method in your Groovy classes, the method will not be called, directly, as in Java, but by invoking the aforementioned invokeMethod(..) (which does a whole bunch of reflection and lookups).
Additionally, every GroovyObject has an associated MetaClass. The concepts of method invocation, etc., are similar.

There are other factors that decrease Groovy performance in comparison to Java, including boxing of primitive data types and (optional) weak typing, but the aforementioned concept of runtime meta programming is crucial. You cannot even think of a JIT compiler with Groovy, that compiles Java bytecode to native code to speed up execution.

To address these issues, there's the Groovy++ project. You simply annotate your Groovy classes with @Typed, and they'll be statically compiled to (real) Java bytecode. Unfortunately, however, I found Groovy++ to be not quite mature, and not well integrated with the main Groovy line, and IDEs. Groovy++ also contradicts basic Groovy programming paradigms. Moreover, Groovy++' @Typed annotation does not work recursively, that is, does not affect underlying libraries like GORM or the Grails controllers infrastructure.

I guess you're evaluating employing a Grails project, as well.

When looking at Grails' GORM, that framework makes heavily use of runtime meta programming, using Hibernate directly, should perform much better.

At the controllers or (especially) services level, extensive computations can be externalized to Java classes. However, GORMs proportion in typical CRUD applications is higher.

Potential performance in Grails are typically addressed by caching layers at the database level or by avoiding to call service or controllers methods (see the SpringCache plugin or the Cache Filter plugin). These are typically implemented on top of the Ehcache infrastructure.
Caching, obviously, may suit well with static data in contrast to (database) data that frequently changes, or web output that is rather variable.

And, finally, you can "throw hardware at it". :-)

In conclusion, the most decisive factor for or against using Groovy/Grails in a large-scaling website ought to be the question whether caching fits with the specific website's nature.

EDIT: As for the question whether Java's JIT compiler had a chance to step in ...
A simple Groovy class

class Hello {
    def getGreeting(name) {
        "Hello " + name
    }
}

gets compiled to

public class Hello
  implements GroovyObject
{
  public Hello()
  {
    Hello this;
    CallSite[] arrayOfCallSite = $getCallSiteArray();
  }
  public Object getGreeting(Object name) { 
    CallSite[] arrayOfCallSite = $getCallSiteArray(); 
    return arrayOfCallSite[0].call("Hello ", name);
  }

  static
  {
    Long tmp6_3 = Long.valueOf(0L);
    __timeStamp__239_neverHappen1288962446391 = (Long)tmp6_3;
    tmp6_3;
    Long tmp20_17 = Long.valueOf(1288962446391L);
    __timeStamp = (Long)tmp20_17;
    tmp20_17;
    return;
  }
}

This is just the top of an iceberg. Jochen Theodoru, an active Groovy developer, put it that way:

A method invocation in Groovy consists usually of several normal method calls, where the arguments are stored in a array, the classes of the arguments must be retrieved, a key is generated out of them, a hashmap is used to lookup the method and if that fails, then we have to test the available methods for compatible methods, select one of the methods based on the runtime type, create a key for the hasmap and then in the end, do a reflection like call on the method.

I really don't think that the JIT inlines such dynamic, highly complex invocations.

As for a "solution" to your question, there is no "do it that way and you're fine". Instead, the task is to identify the factors that are more crucial than others and possible alternatives and mitigation strategies, to evaluate their impact on your current use cases ("can I live with it?"), and, finally, to identify the mix of technologies that meets the requirements best (not completely).