I ran a few tests. First the 2 tests from Rev 45. Then NORMAL sync, and finally bump the cache up to what sqlite3 needs vs an arbitrary 100M. I think the question should be how well does it perform in cache -- not necessarily how much cache it needs. How much cache is just a comparision of memory usage and not performance.
LevelDB: version 1.2 Date: Sat Jul 30 07:28:25 2011 CPU: 16 * Intel(R) Xeon(R) CPU E5520 @ 2.27GHz CPUCache: 8192 KB Keys: 16 bytes each Values: 100 bytes each (50 bytes after compression) Entries: 1000000 RawSize: 110.6 MB (estimated) FileSize: 62.9 MB (estimated) WARNING: Snappy compression is not enabled ------------------------------------------------ fillseq : 1.981 micros/op; 55.8 MB/s fillsync : 81.243 micros/op; 1.4 MB/s (1000 ops) fillrandom : 4.597 micros/op; 24.1 MB/s overwrite : 7.487 micros/op; 14.8 MB/s readrandom : 12.324 micros/op; readrandom : 11.035 micros/op; readseq : 0.349 micros/op; 316.6 MB/s readreverse : 0.623 micros/op; 177.5 MB/s compact : 1328075.886 micros/op; readrandom : 7.779 micros/op; readseq : 0.294 micros/op; 375.8 MB/s readreverse : 0.546 micros/op; 202.6 MB/s fill100K : 1247.163 micros/op; 76.5 MB/s (1000 ops) crc32c : 5.953 micros/op; 656.2 MB/s (4K per op) snappycomp : 1.907 micros/op; (snappy failure) snappyuncomp : 4.053 micros/op; (snappy failure) acquireload : 0.852 micros/op; (each op is 1000 loads) ======================================================================== SQLite: version 3.7.7.1 Date: Sat Jul 30 07:33:48 2011 CPU: 16 * Intel(R) Xeon(R) CPU E5520 @ 2.27GHz CPUCache: 8192 KB Keys: 16 bytes each Values: 100 bytes each Entries: 1000000 RawSize: 110.6 MB (estimated) ------------------------------------------------ fillseq : 24.715 micros/op; 4.5 MB/s fillseqsync : 155.643 micros/op; 0.7 MB/s (10000 ops) fillseqbatch : 9.596 micros/op; 11.5 MB/s fillrandom : 39.831 micros/op; 2.8 MB/s fillrandsync : 166.184 micros/op; 0.7 MB/s (10000 ops) fillrandbatch : 28.292 micros/op; 3.9 MB/s overwrite : 57.128 micros/op; 1.9 MB/s overwritebatch : 50.828 micros/op; 2.2 MB/s readrandom : 13.198 micros/op; readseq : 10.130 micros/op; fillrand100K : 931.480 micros/op; 102.4 MB/s (1000 ops) fillseq100K : 896.252 micros/op; 106.4 MB/s (1000 ops) readseq100K : 152.460 micros/op; readrand100K : 148.244 micros/op; PRAGMA synchronous = NORMAL fillseqsync improves by almost 4X and fillrandsync by 3X as expected. ======================================================================== SQLite: version 3.7.7.1 Date: Sat Jul 30 07:43:17 2011 CPU: 16 * Intel(R) Xeon(R) CPU E5520 @ 2.27GHz CPUCache: 8192 KB Keys: 16 bytes each Values: 100 bytes each Entries: 1000000 RawSize: 110.6 MB (estimated) ------------------------------------------------ fillseq : 24.325 micros/op; 4.5 MB/s fillseqsync : 42.614 micros/op; 2.6 MB/s (10000 ops) fillseqbatch : 9.451 micros/op; 11.7 MB/s fillrandom : 41.009 micros/op; 2.7 MB/s fillrandsync : 49.857 micros/op; 2.2 MB/s (10000 ops) fillrandbatch : 27.605 micros/op; 4.0 MB/s overwrite : 55.803 micros/op; 2.0 MB/s overwritebatch : 49.941 micros/op; 2.2 MB/s readrandom : 13.245 micros/op; readseq : 10.171 micros/op; fillrand100K : 932.312 micros/op; 102.3 MB/s (1000 ops) fillseq100K : 936.597 micros/op; 101.8 MB/s (1000 ops) readseq100K : 158.700 micros/op; readrand100K : 153.880 micros/op; cache_size=409600, page_size=4096 -- no reason to put this at 100M since that's not the actual size of the database -- just let it use as much memory as it needs since sqlite3 only allocates what's needed. The last 4 tests show 2X,2X,6X,6X improvement ======================================================================== SQLite: version 3.7.7.1 Date: Sat Jul 30 08:03:14 2011 CPU: 16 * Intel(R) Xeon(R) CPU E5520 @ 2.27GHz CPUCache: 8192 KB Keys: 16 bytes each Values: 100 bytes each Entries: 1000000 RawSize: 110.6 MB (estimated) ------------------------------------------------ fillseq : 25.911 micros/op; 4.3 MB/s fillseqsync : 56.106 micros/op; 2.0 MB/s (10000 ops) fillseqbatch : 8.265 micros/op; 13.4 MB/s fillrandom : 40.939 micros/op; 2.7 MB/s fillrandsync : 65.621 micros/op; 1.7 MB/s (10000 ops) fillrandbatch : 23.810 micros/op; 4.6 MB/s overwrite : 58.149 micros/op; 1.9 MB/s overwritebatch : 45.118 micros/op; 2.5 MB/s readrandom : 8.053 micros/op; readseq : 7.050 micros/op; fillrand100K : 486.478 micros/op; 196.1 MB/s (1000 ops) fillseq100K : 486.274 micros/op; 196.2 MB/s (1000 ops) readseq100K : 26.951 micros/op; readrand100K : 27.918 micros/op; Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate ________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Alexey Pechnikov [pechni...@mobigroup.ru] Sent: Saturday, July 30, 2011 2:18 AM To: sqlite_us...@googlegroups.com; General Discussion of SQLite Database Subject: EXT :Re: [sqlite] LevelDB benchmark 2011/7/30 Gabor Cselle <ga...@google.com>: > 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 You may use "PRAGMA synchronous = NORMAL" instead of "PRAGMA synchronous = FULL" in WAL mode. -- Best regards, Alexey Pechnikov. http://pechnikov.tel/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
