zhrahman wrote: > Few other info > I am running it on Linux. So to make the long story short, kindly suggest > how to properly have the database shared in memory among n number of > processes. So they can execute select operatins(read only no update on teh > database) effeciently. >
Multiprocessing is a magic trick. The slight of hand makes the system appear to be faster running multiple tasks by relying upon different processes or threads needing access to different interrupts in a given period of time. We can go back to the ancient days of punched cards and line printing to make a simple example. The card reader takes time to process data. While a given process is waiting on the card reader, another process can chunk through some computations. Meanwhile, those computations can be interrupted to let another process send data to a printer buffer which soon fills up and that process has to wait. Back to computations. Now the card reader buffer is full and can be processed so we switch over there. You get the idea. From the outside it looks like the system as a whole runs faster, but it's an illusion. We're just making use of dead time. If you throw nearly identical processes into the mix, such as you are doing, you defeat the magic. Suddenly, you're back to no better than serially processing the data, with the penalty of task switching added in. Given a quad core processor, you would likely be further ahead with three forced processes dividing the work among three cores -- leaving the fourth core for operating system processing. You gain nothing by throwing more processes at the problem. John Elrick _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
