>2. Running the same example on sqlite *file *(multi threaded mode; >WAL journal) scales almost linearly; so 6 threads provide nearly 6xN >throughput. Single threaded throughput is a bit slower (around 15- >20%) than single threaded in-memory access (expected).
So, there is some "part" of the process that is "inherently parallelizable" and you have managed to have a one "thread" to some work during the time some "other thread" is consumed doing something you cannot see. Congratulations. This will increase by diminishing returns. Eventually adding more parallelism will make things slower. >So, memory sqlite is not really usable with multiple threads >(readers). While one might expect that multiple readers of >*memory *content could scale even better than with file content. I would expect that a single connection to a single in memory database is 100% efficient and cannot be further optimized, and therefore I would not try. Why would I (or anyone of sound mind) want to insert "inefficiencies" so that one can then spend inordinate amounts of time to never quite eliminate them, and only go forever slower in the process? _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
