On Aug 2, 2009, at 6:25 PM, Kosenko Max wrote: > > 9/30054 means 99.97% tests are working. > That's a great achievement anyway. > Performance problems can be profiled and optimized simpler than with > native > version. > > That isn't a nature of managed code to be slow. i.e. Perst DB which is > managed from scratch is same speed or faster than SQLite (especially > on > embedded platforms). That's not because of C#, but because of > different > architecture, but still it shows that there are plenty of room. So > don't > froze this project please - there is a high demand on it exist.
This was the conclusion of McObject's (the maker of Perst) investigation. See here: http://www.mcobject.com/march9/2009 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. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
