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).

1 comment:

  1. I'd be interested in your benchmarks using Apache Commons Lang 3.x FastDateParser and FastDateFormat. These classes are thread safe and support the same format/parse pattern specifications as SimpleDateFormat.