Issue 1: Size -- I converted a two-column 230k row table into a DBM::Deep and a DB_File database respectively. The 14 Mb SQLite file became a 25 Mb DBM::Deep file, but shrank to a 5 Mb DB_File file.

Issue 2: Spped -- A simplistic benchmark of counting the number of records in the table gave the following

Benchmark: timing 1 iterations of DB_File, DBM::Deep, SQLite  3...
 DB_File:2 wallclock secs ( 1.90 usr +  0.15 sys = 2.05 CPU) @  0.49/s
+ 
 DBM::Deep:93 wallclock secs (79.24 usr +  9.42 sys = 88.67 CPU) @ 0.0
+1/s 
 SQLite  3:0 wallclock secs ( 0.04 usr +  0.01 sys = 0.05 CPU) @ 19.61
+/s
[download]

My code was simple "SELECT COUNT(*) FROM sqlitedb" for the SQLite db, and "return scalar keys(%$db)" for the other two databases. Is this expected (in particular, is the slowness of DBM::Deep expected, or is there a better way to do this query?

DBM::Deep is Pure perl. It also encodes the Perl data structure in it. Neither DB_File or SQLite does that. So, it's obviously going to be quite slower and somewhat bigger.

Plus, keys() in DBM::Deep is very unoptimized. Most of the code is, right now. That's one reason I took it over.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Actually, I don't mind bigger that much. I just wanted to confirm if I was doing something wrong, and if there was any other way of getting a count of all the records.

Once I know all the "gotchas" I can make a decision.

Many thanks,

--

when small people start casting long shadows, it is time to go to bed