StackHolder - Jakub Kubrynski

I haven't used Groovy for 2 years, since my last touch with Grails . I get stuck in (hard)core Enterprise Java, with some performance aspects in background. I've almost missed a chance to learn Spock , but fortunately Warsaw Java User Group helped me to snap out of some legacy systems and back to normal self-development. In fact I hope that frameworks such as Spock or Geb will change approach to writing tests, by making them easier and more effective. Both frameworks use Groovy, as well as the new king in build tools - Gradle . Seeing pace how Groovy impacts our daily routines I decided to look closer at its performance, and compare it to Java 7. My test environment is based on Java 1.7.0_25 and Groovy 2.1.6. As always in such comparisons I used Caliper  in version 1.0-beta-1 (almost stable) and prepared a number of (I hope) representative microbenchmarks. First benchmark based on Fork/Join framework should be most similar in both languages, because it uses some nati...

Lots of us faced with some performance challenge encountered the problem with the right measuring time of some method invocation, loop iteration, etc. The first solution that comes to mind is to use System.nanoTime() before and after execution. And after subtraction we will get our result. But are we sure that the simplest answer is also the best one? What about comparing multiple measurements? What about JIT impact? Fortunately, a new king is in town - the Caliper. It solves all these problems and protects us from committing other standard errors. It’s not my idea to write another tutorial (those available in Caliper’s source repository are good enough to start using this framework). Instead, let's go into details of how to interpret obtained results and choose the right parameters to perform benchmark. The first important thing that Caliper does is it creates full scenarios cartesian using: defined virtual machines benchmark methods (for time measurements it should be pu...