use Perl

• DB Benchmarks (Score:1)

  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

  Reply to This

  • Re:DB Benchmarks (Score:2)

    by Matts (1087)

    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.
    • Re:DB Benchmarks (Score:1)

      by perrin (4270)

      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.
      • Re:DB Benchmarks (Score:2)

        by Matts (1087)

        Probably so. If you want to send me the code I'll take a look and see if there's any obvious problems.
        • Re:DB Benchmarks (Score:2)

          by Matts (1087)

          I should clarify - I meant if there are any obvious problems in DBD::SQLite :-)
          • Re:DB Benchmarks (Score:1)

            by perrin (4270)

            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.
  • Re:DB Benchmarks (Score:1)

    by perrin (4270)

    I'm not quite sure I trust these, since GDBM is definitely not faster than BerkeleyDB when you use the right API.
    • Re:DB Benchmarks (Score:1)

      by trachtenberga (3651)

      Interesting. In my experience, George's stuff is usually pretty good. Since I didn't run the tests, I don't know which API he used.