Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by trachtenberga (3651) on 2004.11.30 2:15 (#36410)

    George Schlossnagle posted some interesting performance benchmarks [schlossnagle.org] on reading from embedded databases.

    I was surprised to see how crappy SQLite was, especially in the wake of all the earlier raves I'd read about it compared to MySQL for SELECTs.

    -adam

    • SQLite's a full database though. I suspect it would be fairly nippy if you could go straight to its btree API.

      It also makes a difference how you execute the query. i.e. do you cache the statement handle, do you use bound variables for the output, etc.
      • In my tests I did use all the DBI speed tricks. There seem to be a couple of new SQLite-specific things I should try, but I suspect this (simple primary key lookups) is just a hard thing to compete with MySQL on.
        • Probably so. If you want to send me the code I'll take a look and see if there's any obvious problems.
          • I should clarify - I meant if there are any obvious problems in DBD::SQLite :-)
            • What I'm doing is releasing a cache abstraction module to CPAN (tentatively named Cache::Wrapper) which will include a DBD::SQLite version. Then I'll put out my benchmark code that uses it, and people can use it for their own tuning and comparisons.
    • I'm not quite sure I trust these, since GDBM is definitely not faster than BerkeleyDB when you use the right API.