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.
DataNucleus 
Thanks, my app still works on v3.2.13, will be great to see better performance after upgrade. Thanks for your great job.
LikeLike
I would love to upgrade to 4 or 5, but still STUCK with version 2.1.2, because 2.1.3 REMOVED
Persistence property datanucleus.attachPolicy
LikeLike
As you have been told multiple times over the last 10 yrs, if you have a “problem” you have to demonstrate it, and you have continually refused to engage with that process.
DataNucleus passes all instances of the JDO TCK and that API is suitable for a very wide variety of applications, none of which have your “problem”. The JDO TCK demonstrates detaching and attaching, and covers all use cases that are considered required for an application
LikeLike
As i have told you back many times, i was not able to write a “simple” TEST CASE to prove my point! The incompatibility with your claims (“Persistence property datanucleus.attachPolicy is now removed, and the default handling ***should*** work fine”).
Well, the default handling DOES not work fine! I can prove it by sending you the complex persistence code that we use on our app (that DELETES and PERSISTS in the same transaction). I tried several times to reproduce this in a simple test case and failed to do it, YET, under our app code, the new ***attachPolicy*** FAILS miserably!
LikeLike
v6.0 reduces those timings even further, by around 15% on each of the three numbers.
LikeLike
It’s great to see how DataNucleus evolved over time… this is (by far!!!) the best persistence engine out there! No doubt about it.
LikeLike