The arguments here are simplified, and assume some things that may or may not be true. The server I keep in my garage has 16 real cores, 32 threads. More importantly, it uses DDR4 memory which I think means there are 4 channels to memory which can be used in parallel -- perhaps not on exactly the same address but the memory is spread among 16 DIMMs. (It's a System76 "Silverback" with 256 GB RAM). Lots of opportunities for parallelism. Moreover, depending on the actual work to be done, there may be a considerable amount of "inherently parallelizable" work. You don't know until you try it -- or better yet, measure it.
Sure, there will be limits to how far this can go, but modern machines are designed to take advantage of opportunities for parallelism. You just have to get rid of unnecessary locking. So I repeat, why is a read-only database being serialized at all? On Sun, May 13, 2018 at 8:08 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > > >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 > -- Dictionary.com's word of the year: *complicit* _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
