I have. I placed software hooks into the SQLite memory heap manager and determined that SQLite allocates memory for most operations and does not give the memory back until it closes. I didn't look any further as we are out of time. Ray
---- Kalyani Tummala <[EMAIL PROTECTED]> wrote: > Hi Joe, > Yes, SDRAM is normal volatile RAM. Instead of BEGIN ... COMMIT, I have > opened database before insert statement and closed db after that, with > 2500 records already stored in the database, temp_store set to 0(file > always), sqlite is taking 48K heap to open the database, 55K for first 5 > inserts and increases for every other insert and goes to 68K for next 5 > inserts. With temp_store set to 3(memory always), it is reaching 78K. > > Increasing PAGE size increases STACK consumption, which is again a > problem with little main memory. > > So, I think, as the database grows, the initial heap required by an > insert or update statement grows. Can we have control over max heap > usage by sqlite? Did anyone experience before this growth in heap usage? > Are my numbers correct? This is going to be a bottleneck for my > application. > > Thank you > Kalyani > > -----Original Message----- > From: Joe Wilson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 29, 2007 9:40 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] How to restrict the peak heap usage during > multiple inserts and updates? > > The default is auto-commit, so unless you've opened an explicit > transaction > with BEGIN and do a number of inserts, the COMMIT suggestion is not > useful > in reducing memory footprint. > > (apologies in advance if this is obvious...) > SDRAM is the normal volatile RAM, right? > You know that temp_store is competing with sqlite for your RAM. > If you point your temp_store to "disk" to use non-volatile storage > (disk or flash) then you'd have more RAM available for sqlite. > Or do you lack such non-volatile storage? > > You can run the tests on Windows by installing either Cygwin or > MinGW/MSYS, installing Tcl 8.4, running configure, and then running > "make test". > You can change the generated Makefile to define various sqlite > compile-time > flags for memory debugging. Just scan the ifdef's in the source code for > ideas what to enable. It's much easier to do this under Linux than under > > Windows, in my opinion. > > --- Kalyani Tummala <[EMAIL PROTECTED]> wrote: > > My temp_store is SDRAM. Thanks for your suggestion of using COMMIT. I > > have not used it. Any other pointers? > > > > Best Regards > > Kalyani > > > > > > -----Original Message----- > > From: Joe Wilson [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 29, 2007 10:27 AM > > To: sqlite-users@sqlite.org > > Subject: Re: [sqlite] How to restrict the peak heap usage during > > multiple inserts and updates? > > > > --- Joe Wilson <[EMAIL PROTECTED]> wrote: > > > > I am working at porting sqlite ( ver 3.3.8 ) on an embedded device > > with > > > > extremely low main memory. > > > > > > > > I tried running select queries on the tables( with about 2k > records > > each > > > > having about 5 strings) and they do well within 20kB of runtime > heap > > > > usage. > > > > > > > > But, when I try new insertions, the heap usage grows tremendously > > (about > > > > 70 kB at peak). > > > > > > Perhaps preparing the statements (sqlite3_prepare) might decrease > RAM > > > use somewhat. > > > > > > Can you post an example of your schema and these insert statements? > > > > Is your temp_store in memory or flash ram or other? > > > > Another thought... are you performing a COMMIT after each INSERT? > > (or at least every X inserts, where X<100)? > > It might help to reduce memory (at the cost of reduced speed). > > > > > ________________________________________________________________________ > ____________Get the free Yahoo! toolbar and rest assured with the added > security of spyware protection. > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php > > ------------------------------------------------------------------------ > ----- > To unsubscribe, send email to [EMAIL PROTECTED] > ------------------------------------------------------------------------ > ----- > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > [EMAIL PROTECTED] > ********************************************************************** > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
