gerpux wrote: > > I've heard that the guys at db4o said that, under certain > circunstances, db4o is 500x faster than sqlite: > Is this because of the jdbc driver? > What would be a more realistic measure? (db4o is an object database, > not a relational one) > They are using the poleposition benchmark > (http://polepos.sourceforge.net). > Anybody knows if this benchmark is accurate for sqlite?
Hi. "db4o OVER 500 TIMES FASTER THAN SQLITE" http://www.db4o.com/about/news/newsletter/2007_11.aspx Hm, interesting...Let's take a closer look. What they are comparing is called Barcelona Circuit: "writes, reads, queries and deletes objects with a 5 level inheritance structure" http://polepos.sourceforge.net/results/html/barcelona_write.html 500x times? On 30000 objects and 100 iterations db4o took 1.3 seconds and SQLite 710 seconds. Do you believe in correct test? So they have B0-B4 classes inherited from each other where B0 is a base one for all. Each has 1 integer field. B2 has an index on the field. WRITE: Creating N objects of class B4 and setting all their fields to values from 0 to N. Commiting all N objects together. READ: Select all B4 objects at once. QUERY: Get count of all objects. Find all B4 objects where B2.i = x. x is rising from 0 to N. Everything in 1 transaction. DELETE: Delete all B4 objects in 1 transaction. The evil is in details as we know... First of all - settings: DB4O no options provided SQLITE: sqlite.autocommit=true sqlite.executebatch=false Now take a look at the code (some run options seems like missing): 1. db4o - sync probably off (at least it's definetly not flushing every transaction). 2. sqlite - sync 100% on. 3. db4o - wrapped with transactions (don't forget #1 - that means it's not even flushing transactions) 4. sqlite - no transactions at all - each insert/update/delete is 100% flushed separately 5. db4o - uses denormalized table - 1 table with 1 binary field with object data + 1 index 6. sqlite - 5 normalized tables with 1 integer field each (+5 own indexes on parentid and no indexes on item id??) + 1 index and separate insert/delete + select makes 5 joins always 7. db4o uses internal cache of queries 8. sqlite prepared statements thrown after each cycle 9. db4o - uses 1 command for every step 10.sqlite statements executed one by one 11.db4o - uses fast cached count 12.sqlite - counts objects on each cycle 13.db4o - caches everything in memory and not using pages (reading chunks) 14.sqlite - small page size and small cache. And don't forget, JDBC driver of SQLite makes additional overhead in contrast. So I will do own tests to see what's the real difference. I'll try .NET provider of SQLite and db4o.NET. And also I'll do the test on the DB size more than available RAM - 100K objects not serious... And will post back later with full code here and DB4O forum. My prediction? I'll do it A LOT faster on SQLite than db4o. -- View this message in context: http://www.nabble.com/db4o-500x-faster-than-sqlite--tp13484012p15231844.html Sent from the SQLite mailing list archive at Nabble.com. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------