Saturday, June 29, 2013

Synchronized vs threadlocal SimpleDateFormat based on JMH

Micro-benchmarks are really hard. If you have seen some in this blog and you think that at least some of them are correct - you are wrong! ;-) Actually I don't think that I would ever really need to do some micro-benchmarks. To the moment all performance optimizations that I have done were about SQL (mostly), or not loading all the data into memory, but loading and processing it in chunks instead, or introducing some caching, or introducing multi-threading, or just rewriting the algorithm from scratch (introduction of multi-threading is usually the complete rewrite too).

But to have some fun (and to have at least anything to write in blog about) I sometimes do such stupid benchmarks. Of course it is better for this fun activity to have at least some similarity to the real world. Recently (maybe not really recently) Oracle Java Performance Team has open-sourced their framework for micro-benchmarks. I decided to try it and rewrote my benchmark for patterns of multi-threaded usage of the standard SimpleDateFormat (why actually use it since we have joda-time for Java <= 7 and new shiny standard datetime api for Java >= 8?). So here is the result of this benchmark on the Core i7-3632QM (laptop) processor.
The code for this can be found here.
I have tried the same benchmark on the Core i7-3770K (desktop) processor also. And here is the graph:
What we can see is the expected result, except that for the synchronized access to the single SimpleDateFormat the results are not very smooth and stable. So here is the same graph with the synchronized access to the SimpleDateFormat measured in 30 iterations (5s each) instead of 10.

This measurement has not cleared anything actually... What I think is that JIT-compilation of of the version with single synchronized SimpleDateFormat is not stable, so the result of the measurement is stable across different iterations of the same run, but is not stable across different runs and maybe contrintuitive for different number of threads in the same run (different methods => different acts of compilation => different code).

Monday, June 10, 2013

First attempt with scala

I decided to try scala once again (all previous attempts did not last long). I have not read any book about scala so far, and this is just dummy attempt, so I tried to use everything that I already know from Java. To my luck I have stumbled on the project by Graham Lea that uses maven for building, spring-mvc as the web-framework and hibernate as a database access layer. This project actually works, so it is possible to try it moving from one working state of the project to the other.
What I have done in my fork so far:

  • maven-eclipse-plugin is a deprecated way of generating Eclipse project files for the maven project, since Eclipse itself has a pretty good support for maven-basd projects. However inside the stable version of Scala-ide a rather old version of Eclipse is used internally, so maven support is not so great, but still it is good enough to not use maven-eclipse-plugin. So I removed its configuration from the project.
  • Selenium tests was the part that didn't work for me in this project (probably because I'm on Linux), so I removed them and started tests using spring-test library.
  • The latter required spring framework upgrade. Also I have upgraded Hibernate and scala and scala-maven-plugin to the latest versions. This required a bit of editing the scala sources and changing the scala-ide installation since different versions are required for scala 2.9.x and 2.10.x.
  • I migrated the project from using Hibernate SessionFactory to EntityManager and spring-data-jpa (scala traits can be used as spring-data repository interfaces). It seems that this way of using Hibernate is a bit more up-to-date and is free from issues like this one, that I trapped into some time ago.
Glitches that I have stumbled over are about Scala-ide and both can be seen in this file:

  • Organizing imports action removes imports in use making compilation to fail (in the file mentioned SpringJUnit4ClassRunner import is removed, but I have seen this in other situations too)
  • Formatting the source remove comments (in the file mentioned the "//TODO..." comment is removed)
So now is the time to read something about scala and all the surrounding magic. Any thoughts on what book or resource should I read?