On Nov 23, 2007 2:19 PM, Sabyasachi Ruj <[EMAIL PROTECTED]> wrote: > I have an application that uses SQLite extensively. > In a part of that application, I need to do the following steps:- > 1. I need to create a thread per request basis. > 2. Open SQLite connection. > 3. Then retrieve data from SQLite and do some calculation. > 4. Construct the result and send. > 5. Then close SQLite connection. > > This type of threads are being created very frequently. > And thats the reason my application is becoming very CPU hungry. > > As I have tested a sample application if I do the same steps above in a loop > in a sample program it takes 30% CPU (It is a decent 3.0 GHz processor). > > But there if I just take out the sqlite3_open and sqlite3_close, it becomes > 0-1%.
Every time you open a SQLite database it needs to parse the database schema, so that seems to be the cause of your high CPU usage. > > So, I want to achieve the same thing in my multi threaded application. > > The following ideas came in my mind:- > 1. I can share open one SQLite connection and share the connection > between threads with PROPER MANUAL synchronization (so that only one > > thread uses the connection at a time). > => This I ruled out because it will introduce unnecessary > waiting. > > 2. Create a pool of SQLite connections and allocate them the threads > on demand > basis. > => This is still in 'idea' phase. > I want to avoid the complexity that it will introduce in the > application. > > Is there any way by which I can optimize my application? > Any of your 2 options would work ok. If you will do mostly reads, options 2 may give you better performance, because many simultaneous readers can access the database at the same time, while when one is writing all others must wait. Regards, ~Nuno Lucas ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
