On Wed, Aug 1, 2012 at 2:43 PM, Black, Michael (IS) <michael.bla...@ngc.com> wrote: > You may be interested in this article: > http://www.drdobbs.com/parallel/multithreaded-file-io/220300055?pgno=2 > > Mutli-threaded reading of multiple files (which is basically what you're > talking about by splitting a file in half) is only faster if you have > multiple disks (in this article that's a RAID-5 system).
Or if you have a network in the way. Think of ql.io (http://ql.io). Think of GDA, a GNOME database API that uses SQLite3 as its client-side engine and virtual tables to access remote databases: since SQLite3 treats each table/index operation as synchronous GDA may not be able to issue remote operations as fast as possible. What would it take to have the core engine do asynchronous operations? First, the backend/virtual table interfaces would have to change to be async-oriented, with functions to start operations and completion notification, and some way to optionally share an event loop with other components. Second the VDBE code (and the supporting VM) would have to have a concept of co-routines, with each co-routine having a scratch memory register space (perhaps for a stack), and a yield-type operation that puts the current co-routine to "sleep" until some completion notification is received and which wakes one co-routine that's ready to run. Worthwhile? Not for disk/memory DBs, no. But between virtual tables (see GDA) and the potential for remote backends, I think the answer is yes. Also, if you look at ql.io, I think you'll really see the value in SQLite being able to do async! Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
