This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I like groovy and i have used it in a small in-house project where we retrieve data from the d/b and display it on the browser. This display seems slower as we are using the htmlbuiler provided by groovy. Because of this slowness, we are planning to choose JAVA instead of groovy for another project.
That is a little different aspect i guess. As they say Groovy is in place to ease up the tasks with more efficiency and betterment towards performance, hearing the slowness caused by Groovy is quite unbelievable! Isn't it?
Groovy is slower than Java (although we get closer with every release).
If for example you do "1+1" in Java, this will not take any time at all. The Java compiler optimizes it to "2". In Groovy "1+1" is short for "new Integer(1).plus(new Integer(1))" which obviously takes some time. Furthermore, the ctor calls and the plus() method call will go through the Groovy method dispatch which takes additional time.
That said, it is very unlikely that users will recognize any difference in application performance between Groovy and Java apps if one of the following is involved: database, gui, networking, web services, file access, external processes. These operations take orders of magnitude longer than any in-memory calculation no matter if called from Java or Groovy.
If your DB/MarkupBuilder dependent app is slow, I advice running it through a profiler to find the real performance hog. Any standard Java profiler will do. In 9 of 10 cases it's the database (but not always!).