itself. However, I'm afraid that this will not lead to the best possible performance.

If you want the best possible performance then don't use SQLite at all and instead make your own file format that exactly meets your needs and tradeoffs (memory, byte ordering, CPU, concurrency etc).

result to the issuer of the command. This approach saves memory, but I'm afraid the the thread switching involved in this design causes too much overhead.

In general the best way to structure applications such as you suggest is to use a queue and have some threads put work on the queues and a pool of threads that execute that work. (The actual work items should be higher level than a single SQL statement).

That makes it easier to split your program such as if you decide to
make the backend be a service or over the network, makes threading
issues less likely since there will be little shared data, and makes
it easy to scale (just add more worker threads on machines with lots
more memory and/or CPU).

Roger

Reply via email to