Some of what I say is similar to Steve Graves’ comment above – some of these operations will be I/O bound and as a result it really matters what kind of guarantees the different databases are offering when you commit changes, for example. It’s valuable to see comparisons, but it is important that they not just be comparisons of some of the default settings in the different products (cache size, for example).

First, thanks for the kind words about the support you received from us. Our commitment to excellent customer support is a great source of pride for us, so the positive feedback is greatly appreciated.

The results are more or less what we would have expected – Perst shows good search performance and not-as-good performance of update requests and iteration. Lower performance of insert/update is caused by short transactions; i.e. a commit is performed after each update. Perst doesn’t like short transactions. If you group multiple changes into each update transaction (which probably more accurately reflects real-world transactions more often than not) then Perst’s performance should be better. For a quick and easy experiment, just try performing a commit after each N-th transaction, and experiment with the value of N.

As to why SQLite and other databases perform better in insert/update, first of all some might implicitly be using delayed or asynchronous commit (changes are written to the database by a separate thread, so commit() actually doesn’t mean that results of this transaction cannot be lost in case of power failure). This is just speculation; someone would need to dig into the internals of the systems to determine if, in fact, that is the case. Unless you explicitly relax it, Perst enforces the ACID properties of transactions.

Another reason can be the log-less nature of the Perst transaction mechanism. Perst has no log file; instead, shadow copies of objects
are created. When the transaction is committed, all modified pages have to be flushed to the disk (the shadow pages become the pages of record). The total size of these pages can be larger than just the modified objects written to the transaction log (i.e. more bytes have to be written because any given page has >1 object on it). Further, random modified pages in Perst can be (and probably are) located in different parts of the disk. Which will require additional disk head positioning (which is the slowest operation – 10msec average disk access time for modern disks) and as a result – worse performance compared to a sequential write to append to a transaction log file.

Concerning iteration speed – RDBMS table records are located together and so makes it possible to scan them very efficiently
(disks perform sequential reads much, much faster than random reads). Remember, tables are organized as rows, so scanning down a table’s rows is very fast. Perst has to deal with much more complex object structure and is oriented to a different access pattern: it is intended that an index is used to locate an object by some key and then some cluster of related objects is accessed using references. So Perst makes an assumption that objects that were created together are also accessed together and it tries to allocate these objects sequentially on the disk (locality of reference). Consequently, objects of different classes are interspersed in the storage, so sequential search will be less efficient in this case since it will require a lot of disk head repositioning.

I hope this helps put some perspective on your results. Feel free to contact us.

regards,
McObject Support

Just wanted to give another option.
VistaDB (this one closely matches SQLCE for compatibility, but has many other features not present in SQLCE).
I’m not working for them. Also I have no real experience with it.
Just thought you might want to check that one out too.

Best regards
Ike

MM2

Greets