db4o Developer Community

I've been hammering my poor laptop mercilessly for the last 48 hours to see what can be done about the db4o insert time problem (with 1 transaction per insert).   This was all done with .NET 2 and db4o 5.7. It turns out that, with flushing turned off, my job object insert time varies very strongly with block size, as follows.     Block size: ...

Carl, Thanks for looking at this in such detail.  Some thoughts… 1. Use fast disk.  Always best, though I'm performance testing on the disk that comes in my laptop.  I figure that if I test all the alternatives on the same hardware, then it's pretty fair! 2. Delete file at start of test.  A sensible precaution.  I was actually doing this in a ...

My results are a little different.  Of course I'm in a different environment (.NET), I have more indexes (3) and I'm saving a small graph of typically 6 sub-objects with each main object.  I'm using db4o 5.7 (results were broadly similar on 5.5).  Here are my results Test 1 - Store 100k objects, 5000 objects per transaction, flushing off, direct ...

I spoke too soon.  8.1mS (with flush turned off) was the average over 10k objects, but carry on up to 25k objects and the average increases to 15mS/insert (with the last 5k averaging over 25mS/insert).  I tried regularly garbage collecting (excluding the time for this from the timings) but no effect. There is very little disk I/O, with the CPU ...

Thanks.  I just tried that:  Results are:   1000 objects per transaction ->  2.5 mS per insert  1 object per transaction, flushing off -> 8.1 mS per insert  1 object per transaction, flushing on -> 190 mS per insert All on v5.7 with .NET 2.0.  So turning flushing off is definitely much better, but 8mS per insert is still not brilliant. The real ...

Just for a minute I thought all would be well when in the 5.7 release bulletin I saw: ''commits on small changes are much faster and memory consumption for commits and queries is much lower''. Heart in mouth I downloaded 5.7, recompiled and re-ran.  Sadly the same result: 2.5mS per insert in batches of 5000 inserts per transaction (which is OK) ...

Hello, I'm doing some tests to compare the performance of db4o with relational options.  In most ways db4o compares very favourably, but in one aspect it seems to fall down badly. When I write objects to the database in transactions of (say) 1000 objects per transaction I get very good performance.  Drop this to one object per transaction and the ...