Java Bean mapper performance tests

As a follow up to my tests with the Introspector from the Java API, I did some more testing with the following Java Bean to Java Bean mappers:

• Commons BeanUtils
• Spring BeanUtils
• Dozer

Furthermore I used my own implementation and an implementation that’s hardcoded by hand.

The Eclipse project with the sample code for this post can be downloaded as tar.gz or zip or can be viewed online here.

Testing

The performance test creates two beans: one is filled and the other gets filled; this is done over and over again in a big for loop. I coded a by hand implementation as a reference to check whether the process of creating all these new objects is slow. This implementation copies the properties from one bean to the other like so:

bean2.setFoo(bean1.getFoo());
bean2.setBar(bean1.getBar());
bean2.setTee(bean1.getTee());

All the other frameworks had to do the same thing. Have a look at the results (note that I set the y-axis to logarithmic scale):

Obviously there’s no problem with all the created objects: the by hand implementation just consists of the created objects and some method calls to copy the properties. This seems to be pretty fast compared to the other solutions.

Let us have a look at a comparison between the by hand implementation and the frameworks when they have to fill 100k objects:

For example: the by hand implementation beats Dozer by a factor of 970, i.e. it’s 970 times faster.

Conclusion

The results can be explained with the different richness of features. My Introspector and the implementation from the Springframework have very few features and are pretty fast. The Commons BeanUtils implementation has a lot of features (e.g. all this DynaBean stuff). And finally Dozer: I haven’t looked at the code yet, but it seems to be very powerful.

So once more it’s a trade-off between speed and features. Obviously you can’t have both so decide which one your application needs.