DataNucleus performance through the releases

Performance isn’t always the primary motivation when we are developing DataNucleus, but it always remains something that we bear in mind when introducing features or rationalising the APIs. As an interesting comparison of how performance has changed since version 3.x here we present the results of 3 “performance” tests that we have in the DataNucleus test suite.

Test 1 : Persist 2000 simple objects, and then start the timer. Then in a single thread, do the following 200000 times : get a PM, call pm.getObjectById on an id, 5 times per transaction, and close the PM. Stop the timer.

Test 2 : Persist 2000 simple objects, and then start the timer. Then in each of 10 threads, do the following 60000 times : get a PM, call pm.getObjectById on an id, 5 times per transaction, and close the PM. Stop the timer.

Test 3 : Start the timer. Get a PM, and start a transaction. Call pm.makePersistent on an A object, with a List containing 1 B object, and a single relation to a C object. Repeat the operation for 100000 times. Every 10000 objects call flush. Commit the transaction and close the PM. Stop the timer.

v5.1 : Test 1 – 10.0 secs, Test 2 – 10.0 secs, Test 3 – 10.5 secs

v5.0 : Test 1 – 10.0 secs, Test 2 – 10.0 secs, Test 3 – 13.0 secs

v4.1 : Test 1 – 10.0 secs, Test 2 – 10.0 secs, Test 3 – 13.0 secs

v4.0 : Test 1 – 10.0 secs, Test 2 – 10.0 secs, Test 3 – 13.0 secs

v3.2 : Test 1 – 16.5 secs, Test 2 – 20.5 secs, Test 3 – 13.0 secs

In earlier versions performance was less than 3.2, but involve having to go back to earlier JREs so data is not available for comparison. The timings were using an embedded H2 database, on an Intel core i5 with 8Gb RAM, running Linux.

So we have a significant improvement in going to v4.x in terms of allocation of PersistenceManager objects, as well as access to some common properties used by the PersistenceManager. And a further improvement in going to v5.1 in terms of persistence operations.

Clearly this is not a precise science and, as we have said in previous blog entries, a benchmark has to be representative of the operations that your application will be doing for it to mean something to you. If anyone has some simple tests that they want to see in our internal performance tests then you can easily contribute them.

 

Advertisements