Dan Kennedy-4 wrote:
> McObject CEO Steve Graves points out that because of limits of the API 
> they were using, SQLite performs each INSERT and DELETE in the test in a
> separate transaction. So the reported times for these tests may be more of
> a measure of the speed of the media than SQLite itself.
> 
> The body of the report shows that SQLite scans (iterates through) rows
> more quickly than Perst does (about 1.5 times faster). But Perst can look
> up individual objects more quickly (about 6 times faster). The comments 
> in the report indicate that SQLite was not using pre-compiled SQL or
> read-only transactions for the object-lookup test, so that gap could
> probably be closed some by better use of the SQLite API. Perhaps more
> importantly though,  Perst is an Object DB, so it is caching the actual
> objects in-memory, whereas SQLite is only caching database pages. I
> haven't much experience with them, but I think Object DBs are usually
> faster for this kind of task. YMMV.

While this is offtopic, I just want to comment that there could be a
problems with any tests around, so you can propose changes to test code if
you feel it could be done better. Test isn't using recreation of commands
with each selects. Same it's not using any advantages given by Object DB
nature (which is only complimentary part of Perst). In reality it was even
strange to see such difference on select performance (even for author).
Read-only transaction and skipping single preparation wouldn't speed-up
SQLite in that test. But it's very possible it can be tweaked more or at
least optimized inside.

I'm not insisting that Perst DB is better (it doesn't have such open license
- it's GPL/commercial license and it's not full-size SQL capable at least),
that was just a sample to show that it's a mistake to think that pure
managed DBs always slower.

-----
Best Regards.
Max Kosenko.
-- 
View this message in context: 
http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24786305.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

Reply via email to