It may not be possible to get peak heap usage down to 30K, but here's
some random ideas:
I imagine you've already tried defining SQLITE_OMIT_* for the features
that you don't need.
Verify that your embedded OS has a space-efficient malloc implementation.
Try to find a realtime graphical heap allocation analyzer for C programs.
I'm just guessing it exists for C, as there are several for Java.
> 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.
Based on these findings, perhaps btree recursion is using that extra
memory on inserts on larger tables?
btree.c:
/*
** This routine redistributes Cells on pPage and up to NN*2 siblings
** of pPage so that all pages have about the same amount of free space.
** Usually NN siblings on either side of pPage is used in the balancing,
** though more siblings might come from one side if pPage is the first
** or last child of its parent. If pPage has fewer than 2*NN siblings
** (something which can only happen if pPage is the root page or a
** child of root) then all available siblings participate in the balancing.
**
** The number of siblings of pPage might be increased or decreased by one or
** two in an effort to keep pages nearly full but not over full. The root page
** is special and is allowed to be nearly empty. If pPage is
** the root page, then the depth of the tree might be increased
** or decreased by one, as necessary, to keep the root page from being
** overfull or completely empty.
**
** Note that when this routine is called, some of the Cells on pPage
** might not actually be stored in pPage->aData[]. This can happen
** if the page is overfull. Part of the job of this routine is to
** make sure all Cells for pPage once again fit in pPage->aData[].
**
** In the course of balancing the siblings of pPage, the parent of pPage
** might become overfull or underfull. If that happens, then this routine
** is called recursively on the parent.
**
** If this routine fails for any reason, it might leave the database
** in a corrupted state. So if this routine fails, the database should
** be rolled back.
*/
static int balance_nonroot(MemPage *pPage){
...
#ifndef SQLITE_OMIT_INTEGRITY_CHECK
/*
** Do various sanity checks on a single page of a tree. Return
** the tree depth. Root pages return 0. Parents of root pages
** return 1, and so forth.
**
** These checks are done:
**
** 1. Make sure that cells and freeblocks do not overlap
** but combine to completely cover the page.
** NO 2. Make sure cell keys are in order.
** NO 3. Make sure no key is less than or equal to zLowerBound.
** NO 4. Make sure no key is greater than or equal to zUpperBound.
** 5. Check the integrity of overflow pages.
** 6. Recursively call checkTreePage on all children.
** 7. Verify that the depth of all children is the same.
** 8. Make sure this page is at least 33% full or else it is
** the root of the tree.
*/
static int checkTreePage(
> 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?
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
