Java Bean mapper performance tests

Java / December 18, 2019

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:

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):
Performance tests

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:

by HandIntrospectorCommonsSpringDozer
by Hand1120610110970

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.

20 thoughts on “Java Bean mapper performance tests”

  2. AA

    I downloaded the sources. There are some issues when measuring the performance this way (PerformanceComparison class):

    • You should only measure the time it takes to fill the bean with another. Now most of the time is spent in your test code.
    • If you only measure a bean with ints (like the test does) you get different results compared to measuring beans that contain objects (often beans contain more objects than primitives).
    • Hand coded simple class that uses introspection is a lot faster (3x faster) if you cache Methods efficiently and use Method.setAccessible(true).

    So, the results give some hint about what’s going on, but I recommend that one should not rely on those figures.

  3. Christian Schenk

    Hi AA,
    you’re totally right that the tests aren’t that accurate. All I wanted to do was to give some hint about the performance for the various implementations – as you suggest we shouldn’t rely on these figures but test the performance in real applications instead for better results.

  5. Pingback: benelog's me2DAY

  7. Smel

    I modified the test to include Orika, and here is the results: http://bit.ly/ogkdsv

    Orika is a Java Bean mapper that recursively copies (among other capabilities) data from one object to another. It performs close to by hand.

  8. Christian Schenk

    Hi Smel,

    thanks for the update on the tests I did. I definitely have to checkout Orika now and thank you for the hint since I know some colleagues who will be interested as well 😉

  9. Anand Kapadia

    Hi Smel,
    Can I have reference link regarding orika. I am using dozzer in my projects regularly. So if you can give. i would be able to think over orika.

  13. Pingback: Technical Diary » Blog Archive » links for 2011-07-21

  18. bartek

    I’ve put JMapper and Orika to test and run them on my computer.

    10      0    1    39   22    29    3  0
100     0    5    24    6    46    1  0
1000    1   32   140   55   265   30  1
10000  11  120   215   20   218  134  9
20000   0   62   229   32   250    6  0
50000   0   88   558   77   628   15  1
100000  1  179  1119  152  1214   33  2

    (last column is JMapper, next one is Orika)

  20. Pingback: Un poco de Herramientas de Mapeo de Beans en Java | Un poco de Java

Comments are closed.