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 3 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]
-
