Database Performance

I almost hesitate to show this data, since one of Dejavu's design goals is to allow you to test which store is best for your data. But here it is anyway--timing results from the test suite on my machine (rev 200).

Python version: 2.4.2
Dejavu version: 1.4.0

Testing burned storage...
Ran zoo suite in: 0:00:01.813000

Testing caching storage...
Ran zoo suite in: 0:00:02.374000

Testing msaccess storage...
Please wait while support for ADO 2.7+ is verified...
ADO Version: 2.80
   (2) warnings
Ran zoo suite in: 0:00:04.636000

Testing mysql storage...
MySQL Version: 4.1.8.nt
Ran zoo suite in: 0:00:07.922000

Testing proxy storage...
Ran zoo suite in: 0:00:02.193000

Testing pypgsql storage...
PostgreSQL 8.0.0rc1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.3.1 (mingw special 20030
Ran zoo suite in: 0:00:09.183000

Testing shelve storage...
Shelve version: 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
Ran zoo suite in: 0:00:02.203000

Testing sqlite storage...
SQLite Version: 3.3.3
Ran zoo suite in: 0:00:16.483000

Testing sqlserver storage...
Please wait while support for ADO 2.7+ is verified...
ADO Version: 2.80
   (2) warnings
Ran zoo suite in: 0:00:05.798000

The burned, caching, and proxy stores each have a shelve store behind them. Keep in mind that the test suite includes calls to create and destroy the entire database, and is most likely not representative of your data, especially in the areas of database size and read-to-write ratio.

I find the SQLite time to be the only significant outlier, that you might point to and say, "avoid using it". Hopefully, someone smart will instead say, "I know how to improve that!" and contribute code. ;) Note that these times don't incorporate the new threaded-writing test that the SQLite manager currently doesn't pass; expect its performance to worsen (waiting for locks and BUSY states to clear) as that gets fixed.