Dan Kennedy-4 wrote: > Earlier I just quoted the conclusions of the McObject report. Maybe I > misunderstood. But now that I have read the benchmark code, I'm curious. > Why is the SQL not being recompiled for each query? Is there some kind of > compiled query cache hiding behind the [db.query()] call in Android? > > Why would it not help to use a read-only transaction? Is SQLite using > exclusive-locking mode? In the tests I've been working on today I've found > that read-only transactions speed up SQLite considerably for this kind of > workload, even when using exclusive-locking mode.
First of all - I was never referring to the published tests, so my assumptions were that in Android test everything went ok. I've asked author what's up. And it's clear that in Android SQLite API there are no options now (or at least not found on test moment) to make SQLite faster. So that can be resolved, but right now test results on Android true. I was doing some personal tests long time ago and after this thread decided to redo same used TestIndex for SQLite and Perst together. SQLITE TEST inserting 100000 records: 00:00:05.2486875 performing 200000 index searches: 00:00:05.6910420 iteration through 200000 records: 00:00:00.6942915 deleting 100000 records: 00:00:01.5555645 PERST TEST inserting 100000 records: 00:00:05.6158515 performing 200000 index searches: 00:00:03.4675515 iteration through 200000 records: 00:00:02.0994750 deleting 100000 records: 00:00:05.9859450 SQLITE TEST inserting 1000000 records: 00:00:44.6846400 performing 2000000 index searches: 00:00:59.2130070 iteration through 2000000 records: 00:00:07.8237180 deleting 1000000 records: 00:00:16.2304065 PERST TEST inserting 1000000 records: 00:01:05.9596455 performing 2000000 index searches: 00:00:53.0913285 iteration through 2000000 records: 00:00:29.4795585 deleting 1000000 records: 00:01:51.0710160 Here is the test file: http://www.nabble.com/file/p24788887/TestIndex.cs TestIndex.cs Everything optimized as much as possible (but staying ACID and doing same operations) for SQLite. Both DB had same page cache size. Perst wasn't tweaked. Difference is that Perst uses objects and for SQLite that was skipped so iteration performance differs. Deletion is really slower because Perst uses separate indices and requires more operations. I don't know whether this can be tweaked, if test author will have a time - he will change a test. Other than deletion performance, everything else looks comparable to me. And I don't know what it might be with Perst tweak. So again - that is just a show that managed DB isn't something that must be much slower (but really Perst/SQLite so different that we mostly measured different architectures). ----- Best Regards. Max Kosenko. -- View this message in context: http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24788887.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
