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] -----------------------------------------------------------------------------
