I'm a bit confused by the following: "The assign 100K or so to each database connection's lookaside memory allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) immediately after it is opened."
If memory is at a premium, why would you reserve a large amount of it for SQLite's "look aside allocator"? (It's really a zone allocator.) This SQLite mechanism ostensibly attempts to trade memory for speed. If memory is at a premium, in this case a fixed upper bound, that trade off doesn't seem to make sense. I would think in a case where memory is tight, zero bytes should be reserved. Jason Boehle wrote: >>>> I have written an application for the iPhone called Grocery iQ that >>>> uses SQLite. I don't link to or use the built-in SQLite library on >>>> the iPhone. Instead, I compile the SQLite amalgamation into the >>>> executable. The SQLite version currently being used in our app is >>>> 3.6.7. >>>> >>> I sent instructions to Brian Killen on how you can download the latest >>> version of SQLite+CEROD. Perhaps recompiling will help. >>> > > Are there any particular bug fixes or changes that you know of that > might address my problem? I'm all for upgrading the SQLite version, > it's just that we will have to do several days of testing to verify it > works well, resubmit to Apple, then wait 5+ days to hear from them if > it works or not. Although given their tech support response times, we > may have all of that done before I ever hear back from them. > > >>>> * before opening the database, the only other SQLite API calls are: >>>> sqlite3_config(SQLITE_CONFIG_HEAP, &mSqliteMemory[0], 3145728, >>>> 512); // mSqliteMemory is declared as: unsigned char >>>> mSqliteMemory[3145728]; >>>> >>> You will probably do better to allocate most of that 3MB to page cache >>> using sqlite3_config(SQLITE_CONFIG_PAGECHACHE, ...). The assign 100K >>> or so to each database connection's lookaside memory allocator using >>> sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) immediately after it >>> is opened. With the above, usually a 100K or so is enough heap, >>> though more might be required if you are holding many prepared >>> statements or if you are using unusually big prepared statements. >>> >>> Oops. I'm late for meeting. More to follow later tonight..... >>> >> As I was saying.... >> >> Use sqlite3_status() to actually measure your memory usage. Make >> adjustments once you know how the memory is being used. Don't guess; >> measure. Also remember that later versions of SQLite use less memory >> for storing prepared statements, so you might want to upgrade if >> memory is an issue. Limit your cache sizes using the cache_size >> pragma. Make use of sqlite3_soft_heap_limit() if you need to. Or >> right a custom pcache implementation that limits the amount of memory >> used for the page cache. >> > > Thank you for the tips on tuning the memory usage. I will definitely > use this advice when working on Grocery iQ 2.0. The way I have it > working now though, I shouldn't be experiencing any problems like > Apple has reported, right? If SQLite fails any allocations, it should > return an error and fail gracefully, correct? > > -Jason > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
