"Marcus Grimm" <mgr...@medcom-online.de> schrieb im Newsbeitrag news:4b9a01e8.2060...@medcom-online.de...
> Increasing the number of threads does affect the overall > read performance slightly, example: > 1 Thread: 11.2 sec > 16 Threads: 8.2 sec > Single Process: 11sec. > > I still would expect a better scaling, ... IMO, what Lukes timings have clearly shown is, that if you would enhance your "single-process-test" to a "multiple, parallel-working-processes-test", that the scaling would work nearly perfectly (as it should). Processes (only running their single "Default-Thread") when working in parallel, would not profit from an enabled Shared-Cache (no matter what the compile- settings or the open-settings are). Nearly the same should be expectable (naively thought) from multiple, parallel threads within one single process. If Shared Cache is "Off" in this mode, then the behaviour should be the same as with multiple-running-processes (each process only running one single thread). In both cases the mem-consumption is higher, since each "worker-thread" or "worker-process" runs its own, separate cache, but the benefits in performance (when all the caches are hot after a while) should not only occur in the multiple-process-scenario. So the question really is, what is different, when we compare the multiple-process-based mode with the multiple-threads mode (Shared-Cache = "Off"). Both modes want to trade memory versus performance, but only the multiple-processes-mode gets the bargain from this exchange currently. One obvious thing (which very well could be the only cause) is, that in process-mode, we have isolated memory - and all the (cross-thread-)Locking-requests are meaningless (don't wait, or cost much performance), because there's only one single thread in each running process. Only the "cross-process-capable locks" near the file-level take effect and ensure correct concurrent behaviour between multiple *processes*. This should work Ok for multiple processes, even when SQLite was compiled in "plain singlethreaded mode". Now, using a similar, singlethreaded (no mutexes, no locking) compiled sqlite3-library should result in the same performance as with multiple-processes, when used from multiple-threads (No Shared Cache). If my assumption is right, that running such a multithreaded scenario against a singlethreaded compiled library performs at the same level as the multiple-processes-scenario, then the question remains, how one could make this mode "secure and usable" in the same way as with the "naturally isolated" process-memory. Speaking only for the Win-platform, thread- local storage comes to mind, or maybe it is enough (when all the larger, important SQLite-object-types are created from the heap - or at least can be forced to...), that the Heap-handle gets created with the appropriate Creation-Flags for secure, threadsafe allocations from this Heap-Handle later on. Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
