On 07/30/2011 04:45 AM, Gabor Cselle wrote:
> Just a heads-up that we just posted an update to the benchmarks:
> - No more superfluous index on the primary key
> - WAL turned on with auto-checkpointing every 4096 pages
>
> http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
>
> A diff of the results is here:
> http://code.google.com/p/leveldb/source/diff?spec=svn45&r=45&format=side&path=/trunk/doc/benchmark.html&old_path=/trunk/doc/benchmark.html&old=44
>
> A new version of db_bench_sqlite3.cc is also included in the same revision.
>
> As predicted by people here, SQLite shows significant performance
> improvements across the board except for large values (which I attribute to
> WAL).
>
> We're planning to put together a benchmark that uses 64-bit integers as
> keys, rather than 128-bit/16-byte blobs (My understanding is that SQLite
> stores 64-bit, not 32-bit integers). I'll post the results to this mailing
> list.
That's correct. 64-bit integers.
> Thanks everyone for your suggestions.
Another one you could do, if you're making changes, is add a
ReadSequential() function to db_bench_sqlite3.cc. Leveldb and KC are
both using an iterator to read the keys sequentially, but SQLite is
doing a separate lookup of each key.
How about something like this:
void ReadSequential() {
int status;
sqlite3_stmt *pStmt;
int i;
std::string read_str = "SELECT * FROM test";
status = sqlite3_prepare_v2(db_, read_str.c_str(), -1, &pStmt, NULL);
ErrorCheck(status);
for (i=0; i < reads_ && SQLITE_ROW==sqlite3_step(pStmt); i++){
bytes_ += sqlite3_column_bytes(pStmt, 1) +
sqlite3_column_bytes(pStmt, 2);
FinishedSingleOp();
}
status = sqlite3_finalize(pStmt);
ErrorCheck(status);
}
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
